Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Relative File Paths Are Not Supported by ENTRYPOINT in Docker Actions #1088

Closed
tahteche opened this issue May 12, 2021 · 4 comments
Closed
Assignees
Labels
bug Something isn't working documentation

Comments

@tahteche
Copy link

On my laptop using relative paths with ENTRYPOINT (exec form) works fine but when I try to run my Docker action in GH Actions I get the following error:

docker: Error response from daemon: OCI runtime create failed: container_linux.go:367: starting container process caused: exec: "./bin/dreamteam": stat ./bin/dreamteam: no such file or directory: unknown.

Here's the last stage of the Dockerfile which has the issue:

FROM adoptopenjdk:11-jdk-hotspot AS execute

WORKDIR /app

# Copy build directory containing build artifacts
COPY --from=build /app/dreamteam-1.0-SNAPSHOT .

RUN pwd \
    && ls -R \
    && ls -l ./bin/dreamteam

# NEVER FORGET TO USE ABSOLUTE PATH!!!
ENTRYPOINT ["./bin/dreamteam"]

Using ls from within the same working directory to test the exact relative path that failed with ENTRYPOINT showed that the file was in the location I expected.
ls -l ./bin/dreamteam

After a couple hours 🙁 I changed the relative path to an absolute one and it worked.
ENTRYPOINT ["./bin/dreamteam"] -> ENTRYPOINT ["/app/bin/dreamteam"]

Like I stated earlier the relative path worked when running Docker locally so I guess this is a bug with GH Actions or at least the difference in behavior should be stated in the documentation for building Docker actions

@tahteche tahteche added the bug Something isn't working label May 12, 2021
@TingluoHuang
Copy link
Member

@tahteche can you share some workflow run logs or a link to your workflow run if your repository is public?

@tahteche
Copy link
Author

tahteche commented May 12, 2021

@TingluoHuang Here's the link to the workflow run that failed before I fixed the issue:
https://github.com/tahteche/springcat/runs/2564064523?check_suite_focus=true

@TingluoHuang
Copy link
Member

@tahteche thanks.

we overwrite the workdir with --workdir /github/workspace, which is causing your problem, I will file an issue to fix the documentation.

@nikola-jokic
Copy link
Contributor

Hi @tahteche, I made a suggestion that is merged to the docs now. Thank you for filing this issue! This also helped us improve the docs so other people don't bump into the same problem. If you have any other suggestions, feel free to comment here, or open another issue.

@nikola-jokic nikola-jokic self-assigned this Feb 7, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working documentation
Projects
None yet
Development

No branches or pull requests

4 participants
@TingluoHuang @tahteche @nikola-jokic and others