Release v2.2.0 changed the order of the post step

[branchgrove]

With the release of v2.2.0 the post step has changed when it runs. Previously it was usually the last step in a job but now it is running earlier than expected. This has broken some of my own post steps which expects the job to be logged in in order to cleanup resources in Azure.

I think it's due to the pre-step being removed by default which changed when the post-step runs.

v2.1.1

pre azure/login
step-1
azure/login
step-2
step-3
step-4
post step-1
post azure/login

v2.2.0

step-1
azure/login
step-2
step-3
step-4
post azure/login
post step-1

I understand that it is not that great that the post step-1 assumes that the job is logged in however the behaviour was unfortunately relied upon. Since we typically pin to @v2 it broke out of the blue and I think this should have been released as 3.0.0.

[YanaXu]

Hi @branchgrove,

Sorry for it. But yes, post step-1 should not rely on post azure/login because the post order can be changed.
For a workaround, you can refer to Enable/Disable the cleanup steps. Set AZURE_LOGIN_POST_CLEANUP to false and it'll disable post azure/login.

[branchgrove]

Thank you for the response @YanaXu,

I do understand that relying on the post step to be the last one is bad however is this not a breaking change regardless? It was even said in #474 by the user that requested the feature that it would be a breaking change. Was this not breaking for all users relying on the pre-step cleanup? The default behaviour changed which is why it should not have been released as a minor version.

[YanaXu]

@branchgrove, this release is a fix and improvement, as I listed in the PR #484. That's why we can't release it with a new major version. I'm sorry for your case is not working. I suggest you pin to v2.1.1 or set the env variables AZURE_LOGIN_POST_CLEANUP and AZURE_LOGIN_PRE_CLEANUP or update the workflow.

[illrill]

Principally, I also think that this should have been a v3.0.0 release. The semantic versioning specification item 8 states:

Major version X (X.y.z | X > 0) MUST be incremented if any backward incompatible changes are introduced to the public API. It MAY also include minor and patch level changes. Patch and minor versions MUST be reset to 0 when major version is incremented.

A change in behavior that affects the expected functioning for users would count as backward-incompatible, even if it doesn’t alter the structural API.

[YanaXu]

Hi @illrill,

While ensuring security and functionality, backward and forward compatibility are always concerns we are considering. However, to be frank, the combination of GitHub Actions with different runners and various use cases in workflows makes the runtime environment we depend on consistently complex. Take the example in #383, where the user has presented a reasonable use case. In this case, we need to ensure that login context will not be cleaned up between multiple logins in the same job. But regarding the current issue, we think that the way it's being used is something we cannot guarantee will always be correct. It goes beyond what a single action can promise. Therefore, we recommend that the user can adjust the workflow.

As for the release version, we always carefully consider the exact version to release and adhere to semantic versioning rules. But, as I outlined in the PR #484, if we release version v3.0.0, users with these issues would need to upgrade to access this update, which isn’t fair to them.

We hope you understand that while we always strive to make this action simple and convenient for users, there will always be situations we cannot fully cover. But we are actively gathering these use cases and will take them as references for future improvements.

[branchgrove]

It is an unfortunate situation for sure but it is clearly a breaking change reworking the default behaviour regardless if the change is a fix or a feature.

But, as I outlined in the PR #484, if we release version v3.0.0, users with these issues would need to upgrade to access this update, which isn’t fair to them.

Well it's either release a minor and break runs for some users whilst fixing it for others or release a major which requires some to bump versions for their workflows to be fixed. Wouldn't a user waiting for a fix monitor the issue and see that they need to update rather than a user with no issues seeing broken pipelines out of nowhere? It is not fair in that sense to anyone either way but what should be the priority?

I don't expect this version to be rolled back or the current version to change. I just hope that it can be avoided in the future by releasing major versions whenever a breaking change is done even if it is regarded as a fix.