Update to handle proposed changes to devcontainer exec command

[stuartleeks]

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:

1. Nothing or update the documentation. This is the simplest implementation but forces users to make changes when the new CLI version is released.
2. Create a release/v0.2 branch, port the CLI handling changes over, and manually create a release.
3. 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)

[chrmarti]

Given that there are two breaking changes we want everyone to adopt and how recent v0.3 is compared to the last v0.2, I agree that updating v0.2 to point to v0.3 once the two changes are in and have seen some testing in v0.3 is the preferred option for me too.

[chrmarti]

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.

Just verified this is correct. Thanks!

[stuartleeks]

Ok, so the next step is to update v0.3 to only use the exit code from devcontainer exec. Once that is in, we can start looking at enabling GH action releases independently of the AzDO extension while giving time for validating the recent changes in the action

[stuartleeks]

Closing this issue as the devcontainer exec changes are handled. Tracking changes to the release process in #232