Update to handle proposed changes to devcontainer exec command (link)
Currently the action/task expects JSON output for all of the CLI commands but there is a proposal to change the CLI to not output JSON for devcontainer exec. I believe that we can update to just use the process exit code for devcontainer exec.Since the existing CLI behaviour is to set a non-zero exit code on errors, we should be fine to make this change ahead of the CLI change so that the CLI update is a non-event for the action.
The slight complication comes in the fact that we created a v0.3 release recently, so there is a high likelihood that there are still a lot of people specifying v0.2 for the GitHub action.
(Note that due to the way Azure DevOps extensions work, those users will be on the latest version, so the area for concern is GitHub action users specifying the v0.2 version)
The current release process couples the version number for the GitHub action and Azure DevOps extension, and the marketplace rules require the versions for the Azure DevOps extension to keep increasing. This means that we don't (currently) have an easy way to release an update to v0.2 to handle the CLI changes.
There are a few options that I can see for handling the v0.2 case once we have released an updated v0.3 version:
- Nothing or update the documentation. This is the simplest implementation but forces users to make changes when the new CLI version is released.
- Create a
release/v0.2 branch, port the CLI handling changes over, and manually create a release.
- Update the
v0.2 tag to point to v0.3. The driver for the version bump to v0.3 was to derisk the recent packaging changes and to enable testing before updating the docs to indicate that there was a new release. I don't believe there are any breaking changes between the two versions
I'm not particularly keen on option 1 as it will likely result in a lot of users workflows breaking until the update the version they are using.
Option 2 was quite appealing to me as it moves us towards being able to create updated releases for older versions. However, with the upcoming deprecation of set-state, we would need to also bring across some further updates from v0.3 to prevent the action from failing when that is deprecated by GitHub.
I'm currently leaning towards option 3 as as first step as it will ensure that users currently on v0.2 aren't broken by either the CLI change or the set-state deprecation. However, this scenario has highlighted the fact that we don't have an easy way to create updated release of non-latest versions. Whichever option we pick, I think we should invest in changes to enable automated publishing of updates to previous versions. This will enable us to add handle any similar future situations more easily, as well as providing a way to easily add messages to previous versions (e.g. an info message that a new version is available, or a warning message informing users about upcoming changes if older versions can't be updated)
Update to handle proposed changes to
devcontainer execcommand (link)Currently the action/task expects JSON output for all of the CLI commands but there is a proposal to change the CLI to not output JSON for
devcontainer exec. I believe that we can update to just use the process exit code fordevcontainer exec.Since the existing CLI behaviour is to set a non-zero exit code on errors, we should be fine to make this change ahead of the CLI change so that the CLI update is a non-event for the action.The slight complication comes in the fact that we created a
v0.3release recently, so there is a high likelihood that there are still a lot of people specifyingv0.2for the GitHub action.(Note that due to the way Azure DevOps extensions work, those users will be on the latest version, so the area for concern is GitHub action users specifying the
v0.2version)The current release process couples the version number for the GitHub action and Azure DevOps extension, and the marketplace rules require the versions for the Azure DevOps extension to keep increasing. This means that we don't (currently) have an easy way to release an update to
v0.2to handle the CLI changes.There are a few options that I can see for handling the
v0.2case once we have released an updatedv0.3version:release/v0.2branch, port the CLI handling changes over, and manually create a release.v0.2tag to point tov0.3. The driver for the version bump tov0.3was to derisk the recent packaging changes and to enable testing before updating the docs to indicate that there was a new release. I don't believe there are any breaking changes between the two versionsI'm not particularly keen on option 1 as it will likely result in a lot of users workflows breaking until the update the version they are using.
Option 2 was quite appealing to me as it moves us towards being able to create updated releases for older versions. However, with the upcoming deprecation of
set-state, we would need to also bring across some further updates fromv0.3to prevent the action from failing when that is deprecated by GitHub.I'm currently leaning towards option 3 as as first step as it will ensure that users currently on
v0.2aren't broken by either the CLI change or theset-statedeprecation. However, this scenario has highlighted the fact that we don't have an easy way to create updated release of non-latest versions. Whichever option we pick, I think we should invest in changes to enable automated publishing of updates to previous versions. This will enable us to add handle any similar future situations more easily, as well as providing a way to easily add messages to previous versions (e.g. an info message that a new version is available, or a warning message informing users about upcoming changes if older versions can't be updated)