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

Working Directory with custom images #37027

Open
1 task done
richseviora opened this issue Mar 21, 2025 · 5 comments · May be fixed by #37028
Open
1 task done

Working Directory with custom images #37027

richseviora opened this issue Mar 21, 2025 · 5 comments · May be fixed by #37028
Labels
content This issue or pull request belongs to the Docs Content team needs SME This proposal needs review from a subject matter expert

Comments

@richseviora
Copy link

Code of Conduct

What article on docs.github.com is affected?

https://docs.github.com/en/actions/writing-workflows/choosing-where-your-workflow-runs/running-jobs-in-a-container

What part(s) of the article would you like to see updated?

When using a custom image, I've observed that GH Actions appears to be setting the container's work directory to its own custom directory. In my case it's __w/server/server. Therefore, any bash command I would've ran as-is successfully fails until I set the working-directory option to the correct value.

I don't know exactly how that value is being set, though it certainly appears to align with the volume paths captured here.

Additional information

I can confirm that setting the working-directory fixed my problem, but I don't know what's causing the issue and therefore what conditions it presents itself in.

@richseviora richseviora added the content This issue or pull request belongs to the Docs Content team label Mar 21, 2025
Copy link

welcome bot commented Mar 21, 2025

Thanks for opening this issue. A GitHub docs team member should be by to give feedback soon. In the meantime, please check out the contributing guidelines.

@github-actions github-actions bot added the triage Do not begin working on this issue until triaged by the team label Mar 21, 2025
@richseviora richseviora linked a pull request Mar 21, 2025 that will close this issue
3 tasks
@Sharra-writes Sharra-writes added needs SME This proposal needs review from a subject matter expert and removed triage Do not begin working on this issue until triaged by the team labels Mar 21, 2025
Copy link
Contributor

Thanks for opening an issue! We've triaged this issue for technical review by a subject matter expert 👀

@Sharra-writes
Copy link
Contributor

@richseviora Thank you for opening this issue! I'll get this triaged for review. ✨ Our team will provide feedback regarding best next steps. Thanks for your patience!

@Sharra-writes
Copy link
Contributor

@richseviora While we're waiting for an SME review, one of the members of the team found this article and wondered if you had read it/if it could help with the problem you're encountering. 💛

@richseviora
Copy link
Author

Hi @Sharra-writes! Thanks for that link! This feels related to the issue I encountered. I didn't find it when I first went looking for this issue. Given that this article is all about the specific way that GHA uses Docker images, I wonder if it'd make more sense for the documentation in the article I first linked to link to this article?

... actually, on second thought, I think this article is definitely related to my issue and could have the same root cause, but I think the presentation is a bit different. Which I think is actually a really helpful distinction, at least it is for me and my mental model :)

The article you linked to is written in the context of creating a custom GH action, whereas I'm trying to use a prebuilt image here in a GH workflow. So some of that article's instructions appear to be relevant (like the WORKDIR inhibition), but I think they're not exactly on point because my container is already built and therefore the image could never build incorrectly as it would were the image being built on your servers. It's just not going to be executed correctly b/c the docker create command being run by the workflow is overriding the work dir (see the --workdir option):

 /usr/bin/docker create --name XXX_dkrecruswest2amazonawscomXXX_fadae2 --label 6f0ad1 --workdir /__w/server/server --network github_network_YYY  -e "HOME=/github/home" -e GITHUB_ACTIONS=true -e CI=true -v \
"/var/run/docker.sock":"/var/run/docker.sock" -v "/home/runner/work":"/__w" -v \
"/home/runner/runners/2.323.0/externals":"/__e":ro -v "/home/runner/work/_temp":"/__w/_temp" -v \
"/home/runner/work/_actions":"/__w/_actions" -v "/opt/hostedtoolcache":"/__t" -v \
"/home/runner/work/_temp/_github_home":"/github/home" -v "/home/runner/work/_temp/_github_workflow":"/github/workflow" --entrypoint "tail" XXX.dkr.ecr.us-west-2.amazonaws.com/sweatrecord-app:XXX "-f" "/dev/null"

I was going to suggest linking to that article, but given that the context is different I'm left wondering whether that's the right thing to do. What do you think?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
content This issue or pull request belongs to the Docs Content team needs SME This proposal needs review from a subject matter expert
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants
@richseviora @Sharra-writes and others