Commands Specified in devcontainer.json Fail in GitHub Actions

[Olgethorpe]

I have a CI/CD pipeline that utilizes devcontainers/ci to run relevant test/build commands using GitHub Actions. Prior to the release of devcontainers/cli 0.50.1. All of the devcontainers were able to execute their commands without any issues. Now executing any of the commands after the initializeCommand fail inside of the GitHub Actions runner where they were not before. If I do not specify a runCmd in the devcontainers/ci action's arguments the devcontainer is still able to be built. The devcontainers are able to be built and ran locally when using VSCode and everything works as expected.

What I do know when this executes is as follows:

1. The devcontainer is able to be built
2. Upon attempting any command past the initializeCommand it fails with the following error: the input device is not a TTY without any additional explanation

At first I thought some combination of runArgs I could supply to make the devcontainer work again but that does not seem to be the case. Would a feature to use a specific version of the devcontainers CLI be worth implementing?

[khumps]

From the devcontainers/cli release notes

[0.50.1]
Fix: Allocate pty for docker exec (https://github.com/devcontainers/cli/issues/556)
[0.50.0]
Publish without node-pty dependency (https://github.com/devcontainers/cli/pull/585)

I can only assume something here broke functionality. Definitely agree with @Olgethorpe that pinning the version of the cli (or at least an action argument allowing it to be pinned) should probably be added. Pinning the version of the action and having outside changes still break things isn't ideal.

[Carlton-Perkins]

Maybe its a good and simple solution right now to just pin the version in https://github.com/devcontainers/ci/blob/cc80b0ef439af5f89482a346a8362cfb815cd3ca/common/src/dev-container-cli.ts#L8 to 0.50.0 to mitigate?

[Olgethorpe]

I saw that there was logic in place to check if the CLI was already installed.

I think that pinning the CLI version can mitigate the issue for the short term.

I am going to attempt to do the following before the CLI to see if it picks up from an existing installation depending on how fast that change can be moved along.

- name: Install node
  uses: actions/setup-node@v3
- name: Install pinned version of devcontainers cli
  shell: bash
  run: |
    npm install --global @devcontainers/[email protected]
- name: Build/Run the devcontainer
   uses: devcontainers/[email protected]
   with:
       ...

[Carlton-Perkins]

@Olgethorpe Looks like that mitigation works for us. Thanks for the find!

[Olgethorpe]

I think the above PR should be the long-term solution in specifying version to reduce overhead runtime code setting up node and installing an additional package to preserve more GHA minutes for the devcontainer image rather than the overhead of GHA wrapping the required tools for this tool.

[stuartleeks]

@chrmarti - I'm off currently, but also hit this issue in AzDO builds (the error I see is the input device is not a TTY when it attempts to run the postCreateCommand)

Builds were working fine on 0.50.0 but failing on 0.50.1
`

[vinh0604]

Hi, seems like it's related to the issue I'm facing as well devcontainers/ci#254

[chrmarti]

Fixed in 0.50.2. Let me know if you still see any issues with that. Thanks!

[Olgethorpe]

Fixed in 0.50.2. Let me know if you still see any issues with that. Thanks!

I can confirm, that CI/CD jobs in GitHub actions are no longer reporting the the input device is not a TTY error. Thank you for getting the fix out quickly!