Fixing release workflow #256
Conversation
…ithub workflow. This should fix the failing release publishing now that the command got split into multiple distinct steps
.github/workflows/release.yml
Outdated
| COMMIT_ID=$(git rev-parse HEAD~0) | ||
| echo ::set-output name=APP_MAJOR::${CURRENT_VERSION_PARTS[0]:1} | ||
| echo ::set-output name=APP_MINOR::${CURRENT_VERSION_PARTS[1]} | ||
| echo ::set-output name=APP_PATCH::${CURRENT_VERSION_PARTS[2]} |
There was a problem hiding this comment.
Consider if this step should have an output ala APP_FULL_VERSION since we have many uses where we combine alle of these. This would in my opinion make the rest of the workflow more readable.
echo ::set-output name=APP_FULL_VERSION::${APP_MAJOR}.${APP_MINOR}.${APP_PATCH}
There was a problem hiding this comment.
Smart! I replaced those, as well as those using MAJOR.MINOR, so now there's no more double or triple variable reads on one line.
.github/workflows/release.yml
Outdated
| mkdir -p ./cdn/toolkits/altinn-app-frontend/$APP_MAJOR.$APP_MINOR.$APP_PATCH | ||
| cp -fr ./app-frontend/src/altinn-app-frontend/dist/altinn-app-frontend.js ./cdn/toolkits/altinn-app-frontend/$APP_MAJOR.$APP_MINOR.$APP_PATCH/altinn-app-frontend.js | ||
| cp -fr ./app-frontend/src/altinn-app-frontend/dist/altinn-app-frontend.css ./cdn/toolkits/altinn-app-frontend/$APP_MAJOR.$APP_MINOR.$APP_PATCH/altinn-app-frontend.css | ||
| mkdir -p ./cdn/toolkits/altinn-app-frontend/${{ steps.prepare.outputs.APP_MAJOR }}.${{ steps.prepare.outputs.APP_MINOR }}.${{ steps.prepare.outputs.APP_PATCH }} |
There was a problem hiding this comment.
Is this path correct? It looks the same as the one in the previous step (line 70). Should it be in a prerelease directory or something?
There was a problem hiding this comment.
Right, it possibly should. The thinking in #179 was to add preliminary support for prereleases, or, at least not overwrite the major version if someone checks that box. We could (and should) think this through some more before we go ahead with releasing preview versions en-masse. Right now we're releasing from main, so if we were to release (for example) `v3.45.0-preview1` from a certain feature-branch, there's no guarantee the proper v3.45.0 won't be released without the features in that feature-branch.
And per your suggestion, if we introduce a prerelease folder, that would also complicate the list of versions generated in #179 - and thus it would complicate #8562.
I'm open to any suggestions, but right now it's most important that checking the "this is a prerelease" checkbox doesn't just run the regular release workflow (which overwrites the major version).
There was a problem hiding this comment.
I missed the reply on this (github notifications and I arent best friends 😅)
But it seems like we are overwriting the current patch version on prerelease releases with the current workflow? Or am I misunderstanding?
I am misunderstanding 🙂 We will anyway increase the patch version number on prerelease, so in effect we will get new patch versions, but minor and major will not be modified.
I think the current approach is fine.
There was a problem hiding this comment.
As mentioned in the huddle; no, as long as each new release has its own unique patch version, this overwrites nothing.
|
Kudos, SonarCloud Quality Gate passed!
|
Description
This should fix the failing release publishing now that the command got split into multiple distinct steps
Verification
Documentation