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

[dabrahams]

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.

[chrmarti]

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?

[dabrahams]

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.

[chrmarti]

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.

[dabrahams]

That sounds promising indeed!

[dabrahams]

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.

[chrmarti]

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.