Repository navigation
"Everything in one step" approach clashes with workflows where the dev container is treated as one target platform. #281
Description
Activity
There is no GitHub action runtime inside the dev container that could execute the part of your workflow steps that should run in side the container.
You could use multiple devcontainers/ci action steps though. Does that not work as expected?
It works when it works. I suppose if the step just modifies the filesystem, that's most of the time. However, I still can't describe my CI process in one way that works both on the devcontainer and natively, which means I either need to duplicate and conditionalize each step, or I separate the devcontainer testing from native platform tests.
GitHub Actions support running a job in a container: https://docs.github.com/en/actions/using-jobs/running-jobs-in-a-container
There is currently no support for dev containers for this, but that seems to be the direction you would like us to go.
Reacted by Torsten Marco Lüdtke-KnodtThat sounds promising indeed!
Another possibility would be to provide a
shell:setting that causes aruncommand to run in the devcontainer. That would cover most of my problems.Reacted by Christof MartiMaybe the custom shell support could be used for doing this: https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#custom-shell
I guess currently you might need a helper script to act as the custom shell to make it work.
Well folks. I figured it out!
I'll leave comments below inline to explain things.
- name: Start Dev Container uses: devcontainers/ci@v0.3 with: imageName: ghcr.io/example/example-image # You must have a runCmd defined, so just do a simple echo. Without it, the devcontainers/ci action will not start the container. # Crucially the container is left running which is useful for what we want to do. runCmd: echo "Container started" - name: Example Step # We use a YAML anchor so we don't have to repeat this long string if we want several steps. # This runs the script in the steps via the devcontainer exec CLI, which interacts with the existing # running container. # # Technical details: The {0} is replaced by GHA with a path to a temp file GHA automatically creates containing # the `run` lines. This file is on the runner and not available inside the container. We need to get this file piped # into the stdin of the devcontainer CLI (which is already installed by the devcontainers/ci action). The only way # to do this on GHA is to have a parent shell such that you can use a pipe `<`. We then execute `bash` inside of # the container, but crucially with `-` as its first arg, which will now ingest the script from stdin that we provided. shell: &devcontainer-shell /usr/bin/bash -e -c "devcontainer exec --workspace-folder . bash -e - < '{0}'" run: | echo "I am executing inside the dev container!" - name: Another Step # Reference previously defined anchor shell: *devcontainer-shell run: echo "I am another step executing in the container!"
GHA special files
If you need access to
$GITHUB_OUTPUT,$GITHUB_ENV,GITHUB_PATHor$GITHUB_STEP_SUMMARYyou can take a different approach.Because of an issue with the action where in how it mounts these vars, part of this is it needs a change in devcontainer.json. This could be avoided if there is a change in this library to mount the temp runner dir in its whole.
In devcontainer.json:
"mounts": [ // Used so steps in our Github Actions workflow that are run inside this container have access // to special Github runner file commands, e.g. $GITHUB_OUTPUT { "type": "bind", "source": "${localEnv:RUNNER_TEMP:/dev/null}", "target": "${localEnv:RUNNER_TEMP:/tmp/.gha_no_runner}" } ],
Now we can change the shell command in each step to this new iteration, which works around obstructive overriding from the current impl of this github action.
- name: Step with output id: example-with-output shell: &devcontainer-shell /usr/bin/bash -e -c "devcontainer exec --workspace-folder . --remote-env GITHUB_OUTPUT=$GITHUB_OUTPUT --remote-env GITHUB_PATH=$GITHUB_PATH --remote-env GITHUB_ENV=$GITHUB_ENV --remote-env GITHUB_STEP_SUMMARY=$GITHUB_STEP_SUMMARY bash -e - < '{0}'" run: echo "EXAMPLE=Test output" >> "$GITHUB_OUTPUT" - name: Get example output env: EXAMPLE_OUTPUT: ${{ steps.example-with-output.outputs.EXAMPLE }} run: echo "The step output was $EXAMPLE_OUTPUT"
I might try and put all this in a composite action for easy usage but could also raise a pr on this lib to add a new devcontainer/ci/exec action.
Reacted by Joscha and JVApenChristof Marti (@chrmarti) adamscybot (@adamscybot) : It's been a year since the previous update on this issue, would you be able to give some insights in the progress?
It's awkward that, if there are 10 linearly-dependent steps to testing my project, I have to put them all into one devcontainer
runCmdwhen the devcontainer is treated as a target platform in my matrix strategy. All the other platforms get distinct workflow steps but I have to intentionally not run any of those on the dev container and instead run one unified step.