"Everything in one step" approach clashes with workflows where the dev container is treated as one target platform.

It's awkward that, if there are 10 linearly-dependent steps to testing my project, I have to put them all into one devcontainer runCmd when 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.

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.

That sounds promising indeed!

Another possibility would be to provide a shell: setting that causes a run command to run in the devcontainer. That would cover most of my problems.

Maybe 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_PATH or $GITHUB_STEP_SUMMARY you 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.

Christof Marti (@chrmarti)

Christof 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?

Navigation Menu

Repository navigation

"Everything in one step" approach clashes with workflows where the dev container is treated as one target platform. #281

GHA special files

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

"Everything in one step" approach clashes with workflows where the dev container is treated as one target platform. #281

Description

Activity

chrmarti commented on Apr 10, 2024

dabrahams commented on Apr 16, 2024

chrmarti commented on Apr 19, 2024

dabrahams commented on Apr 25, 2024

dabrahams commented on Apr 25, 2024

chrmarti commented on Apr 30, 2024

adamscybot commented on Sep 14, 2025

GHA special files

JVApen commented on Oct 6, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions