Repository navigation
Commands Specified in devcontainer.json Fail in GitHub Actions #606
Description
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:
- The devcontainer is able to be built
- Upon attempting any command past the
initializeCommandit fails with the following error:the input device is not a TTYwithout 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?
Activity
khumps commentedon Jul 27, 2023
From the devcontainers/cli release notes
I can only assume something here broke functionality. Definitely agree with Dominik Ondusko (@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 commentedon Jul 27, 2023
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.0to mitigate?Olgethorpe commentedon Jul 27, 2023
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.
Carlton-Perkins commentedon Jul 27, 2023
Dominik Ondusko (@Olgethorpe) Looks like that mitigation works for us. Thanks for the find!
Olgethorpe commentedon Jul 27, 2023
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 commentedon Jul 28, 2023
Christof Marti (@chrmarti) - I'm off currently, but also hit this issue in AzDO builds (the error I see is
the input device is not a TTYwhen it attempts to run the postCreateCommand)Builds were working fine on 0.50.0 but failing on 0.50.1
`
vinh0604 commentedon Jul 28, 2023
Hi, seems like it's related to the issue I'm facing as well devcontainers/ci#254
Fix CI (https://github.com/devcontainers/ci/issues/252)
Fix: Only allocate tty for `docker exec` when stdin is a tty (#606)
Fix: Only allocate tty for `docker exec` when stdin is a tty (#606)
chrmarti commentedon Jul 28, 2023
Fixed in 0.50.2. Let me know if you still see any issues with that. Thanks!
Pin devcontainers/cli to 0.50.0
Olgethorpe commentedon Jul 28, 2023
I can confirm, that CI/CD jobs in GitHub actions are no longer reporting the
the input device is not a TTYerror. Thank you for getting the fix out quickly!