CreateRelease action tags wrong commit

[jonaswre]

CreateRelease will release the latest CICD artifact and also tag the latest git commit.

But not in all case this is correct.
It would be better to tag the commit that's actually used in the artifact.

If you want to look at the source code that was actually released you might be looking at the wrong code in the current configuration.

The release rest api allows you to specify a different commit.

[jonaswre]

@freddydk
I've looked at CreateRelease.yaml

The commit used for the artifcat can be gotten from $_.workflow_run.head_sha
The actions/create-release@v1 has an input commitish.

The problem is what commit should be used in multi-project repos?
The latest from all the artifacts? - and then add table to the release notes?

Project	commit
Project1	45feda12
Project2	47daea14

[freddydk]

Looking at this.
I assume that the situation, where you would be in this situation is, if your last build failed (or is currently running)
If you checked in some code, which cannot build and then run Create Release.
Then it would grab the latest successful builds, but it would tag the faulty source code.
Is that the scenario you have in mind?

If this is not the case and the latest CI/CD was successful, then tagging the latest commit should give you the source which was used to provide the bits.
Even in multi-project repos
Yes, the actual bits might be produced by an earlier checkin, but the source code didn't change for these projects since then.

I don't think you can get the workflow_run.head_sha during the create release.
The workflow_run properties are only available in workflows, which got kicked off by a workflow_run event (and only while running) - as far as I know, but I could probably find the SHA elsewhere.

But... first let me understand the issue and whether this is how you see it - and whether this is an actual problem you ran into or a problem you can see will occur?

Thanks

[jonaswre]

I assume that the situation, where you would be in this situation is, if your last build failed (or is currently running)
If you checked in some code, which cannot build and then run Create Release.
Then it would grab the latest successful builds, but it would tag the faulty source code.
Is that the scenario you have in mind?

Yes this is exactly what happened.

In a multi-project repo this failure might not have even been the last run.

Imagine...

1. Project A: Success
2. Project A: Failure
3. Project B: Success
4. Project B: Success
5. Project B: Success

Depending how many project you have and how many build were since that failure It would be easy to overlook this and only realise there was an error after deployment.

I think its not correct to tag the latest since its just not true that the source code present in the latest commit was completely released. But maybe im wrong I havn't had this in a multi project repo.
And I think this should be caught in the Release because the failure might not even be caused by faulty code.

But... first let me understand the issue and whether this is how you see it - and whether this is an actual problem you ran into or a problem you can see will occur?

I actually had this error. And when I deployed the code and didn't find the latest feature, I tried to figure out why the new feature was not present and the first thing I did was to look at the tagged commit. Which I then realised was wrong.

The reason the action failed was because of a 404 error when getting the artifact. - I know there were fixes made to better handle these - but a failure for some outside reason could always happen and would not have been caught in a PR.

Maybe the solution is to fail the release if not all code from the latest commit is released - but this might be difficult to figure out. You would need to iterate through the git history since last release and figure this out.

I don't think you can get the workflow_run.head_sha during the create release.
The workflow_run properties are only available in workflows, which got kicked off by a workflow_run event (and only while running) - as far as I know, but I could probably find the SHA elsewhere.

I havn't actually ran the code. But I would have done the change within this loop

AL-Go/Templates/AppSource App/.github/workflows/CreateRelease.yaml

Line 117 in 1029f0a

$atype = $_.name.SubString(0,$_.name.Length-$artifactsVersion.Length-1)

You request the following endpoint which gives you accest to the workflow_run properties.
https://docs.github.com/en/rest/actions/artifacts

[freddydk]

Got it,
Thanks

[freddydk]

The tag will never be perfect.
We can create a list, but if we create a release branch - it will be wrong.
One thought...
For multi-project repos - we could require that you run (or even invoke if not the case) a CI/CD workflow, which builds all projects before creating the release - that would ensure that source and projects are up-to-date.

[jonaswre]

The tag will never be perfect. We can create a list, but if we create a release branch - it will be wrong.

Even if you create a release branch the commits will still have the same hash. Or do I have something wrong here?

For multi-project repos - we could require that you run (or even invoke if not the case) a CI/CD workflow, which builds all projects before creating the release - that would ensure that source and projects are up-to-date.

I think this could be a good solution - even in single project repos. It would increase the release time, but you could make sure the build you invoked was actually successful, if not - don't release.
And you could tag the commit that was used for the build.

[freddydk]

Even if you create a release branch the commits will still have the same hash. Or do I have something wrong here?

Correct - but the tag cannot tag one SHA for one project and another SHA for another project and if the idea is to be able to create a release branch based on this tag - then that will never work.

Some people are using release branches to create hotfixes from - those might be wrong.

I will look into somehow "demanding" a complete build for a release.
Thanks for this.

[jonaswre]

I will look into somehow "demanding" a complete build for a release.
Thanks for this.

I'm sorry...

[freddydk]

Implementation

• When locating artifacts for the various projects, I locate the SHA used to build the artifact.
• If all projects are not available with the same SHA, I give this error: The build selected for release doesn't contain all projects. Please rebuild all projects by manually running the CI/CD workflow and recreate the release.
• I then use this SHA for creating the release.
• There is no longer a hard dependency on the main branch name from Create Release.

[jonaswre]

I think this is a good compromise.

Thanks