Automise release process #4
Conversation
in order to have a consistent release process among all SDK, first step to create file that checks if there is any changes on the openapi and if yes then update the local openapi file
adding workflow the automate the release process: - increments the artifactVersion (SDK version) - removes the old SDK to avoid any conflicts or not needed files - generate the new SDK with new version and updated openAPI - commit the changes - create new release tag and commit
| on: | ||
| push: | ||
| branches: | ||
| - Automise-release-process # to be changed into main after merge |
There was a problem hiding this comment.
I think you mean 'automate' instead of 'automise'
There was a problem hiding this comment.
No, I meant automise, is another spelling of automize, just forgot "the".
| - Automise-release-process # to be changed into main after merge | ||
| workflow_dispatch: | ||
| schedule: | ||
| - cron: '0 * * * *' # At :00 every hour |
There was a problem hiding this comment.
Why is this 'schedule' trigger needed? AFAIU your other action already triggers on this schedule, which should trigger this action.
There was a problem hiding this comment.
you are right, the initial idea was to put both actions in the same file, I missed it after I separated them, I will remove it, thanks for the feedback : )
| git add sdk/ # Add the generated SDK | ||
| git commit -m "Release ${new_version}" | ||
| git pull --rebase origin Automise-release-process | ||
| git push origin Automise-release-process |
There was a problem hiding this comment.
On line 6 you are triggering when you push to this branch Automise-release-process. That means this action will trigger itself in an infinite loop, right?
There was a problem hiding this comment.
nicely spotted 👌
you are right, this should lead to infinite loop, strangely (lucky) this infinite loop was not triggered.
There was a problem hiding this comment.
I think GitHub Actions may detect an infinite loop and prevent it, but we still shouldn't risk it.
There was a problem hiding this comment.
That makes sense. I agree.
| push: | ||
| workflow_dispatch: | ||
| schedule: | ||
| - cron: '0 * * * *' # At :00 every hour |
There was a problem hiding this comment.
Building SDK every hour sounds way too aggressive, consider that during night and weekends there will never be any openapi spec changes. For me running once per day on workdays is optimal, but even if you limit hourly runs to workdays & work hours is fine.
There was a problem hiding this comment.
Thanks Predrag for the feedback : )
I took this from python-exoscale
Howevrt I agree with, the more longer the less risky, e.g. better to have one bugs-free update than 10 with bugs.
There was a problem hiding this comment.
Understood, I'll create PR to change schedule for python-exoscale as well.
updating the action to be triggered only when there is a change on the opanapi.yaml file this will avoid infinite loop risk.
|
|
||
| steps: | ||
| - name: Checkout | ||
| uses: actions/checkout@v4 |
There was a problem hiding this comment.
I think this always checks out the branch on which the action is performed. But if I understand the purpose of this action, it is to always be executed on the main branch right?
Since releases should always be tagged and built based on the main branch, how about checking out main here directly?
Then you don't need to do the git pull --rebase below, which can actually fail depending on your branch.
Did you test this action? Because I would be surprised if the git push step below actually works without assigning 'content: write' permissions to this Action.
In order to have a consistent process for new SDK releases, this PR introduces two GitHub Actions workflows that automate the process of updating the OpenAPI definition, generating the SDK, and creating a new release.
Two files are added to the GitHub workflow:
Same way in python-exoscale this file checks if there is any changes on the openapi and if yes it updated the local openapi file with new changes and commit the changes.
.github/workflows/generate-and-release.yaml
After new changes in main branch (now the works on "Automise release process") this action gets triggered and does the following:
You can check the action to see the output of these two actions.