-
Notifications
You must be signed in to change notification settings - Fork 50
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update to handle proposed changes to devcontainer exec
command
#223
Comments
Given that there are two breaking changes we want everyone to adopt and how recent |
Just verified this is correct. Thanks! |
Ok, so the next step is to update |
Closing this issue as the |
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 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.3
release recently, so there is a high likelihood that there are still a lot of people specifyingv0.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 updatedv0.3
version:release/v0.2
branch, port the CLI handling changes over, and manually create a release.v0.2
tag to point tov0.3
. The driver for the version bump tov0.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 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.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 theset-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)The text was updated successfully, but these errors were encountered: