refactor: CI/CD Pipelines #259
Conversation
| @@ -19,6 +18,7 @@ env: | |||
| jobs: | |||
| prerequisites: | |||
| name: "Prerequisites" | |||
| if: ${{ github.event_name == 'workflow_dispatch' || (github.event_name == 'pull_request_review' && github.event.review.state == 'approved' && startsWith(github.event.pull_request.head.ref, 'RELEASE-')) }} | |||
There was a problem hiding this comment.
Discussion
We are still having a pull_request_review trigger here. So even though the job would be skipped for any PR that is not coming from a RELEASE-* branch, it would still appear within the status checks of every other PR.
So maybe we should get rid of the automatic trigger altogether?
There was a problem hiding this comment.
would agree, one extra button press isn't the world, better not to have our PR checks (even more) cluttered.. no strong opinion though ofc...
There was a problem hiding this comment.
I removed the automatic trigger and added another checkbox to the release PR body (i.e. Trigger the Perform Release Workflow).
| description: "The username to use when authenticating with the repository." | ||
| required: true | ||
| repository-password: | ||
| description: "The password to use when authenticating with the repository." |
There was a problem hiding this comment.
Not too sure if this is safe to do. Maybe input parameters are logged in plaintext somewhere? Maybe just pass the name of the secret instead?
There was a problem hiding this comment.
Generally, it seems to be a "best practice" to pass around secrets like this
(see the token parameter of the checkout action for example).
But I'd still agree: As this is our own action, we don't need to pass around the actual secrets. Using the secret names should be sufficient 👍
There was a problem hiding this comment.
Unfortunately, passing the secret names (instead of their actual values), doesn't work as it would require some sort of "nested GitHub macro extension" like so:
- run: something
env:
GH_TOKEN: ${{ secrets.${{ inputs.secret-name}} }}This doesn't seem to be supported by GH actions.
Johannes-Schneider
dismissed
CharlesDuboisSAP’s stale review
comments have been addressed.
Context
SAP/cloud-sdk-java-backlog#318
Continuation of #235
This PR refactors our GitHub actions to, first and foremost, avoid the massive code duplication.
Additionally, it also refactors the release flow, which now provides a lot more automation and should be easier to use in general.
How CI Works
The CI portion of our pipelines has been changed in the following ways:
continuous-integration.yaml).mainbranch) receives an update.main-build.yaml, ourprepare-release.yaml, and ourdeploy-snapshot.yaml). This is how we are getting rid of the code duplication.How CD Works
The CD portion (i.e. performing releases) has also been changed.
Here is the new flow:
Prepare Release(prepare-release.yaml) workflow. There are sensitive default parameters in place, so no manual input is required.5.3.0)continuous-integration.yamlworkflow on the release commit. This includes code checks, such as Black Duck, CodeQL, etc.rel/<VERSION>) and also create a new draft release in our GitHub repoPrepare Releaseworkflow succeeds, the release facilitator will find a new PR with detailed instructions about what to do in our Code Repo (i.e.SAP/cloud-sdk-java). These TODOs include the following:release-notes.md)Perform Releaseworkflow will be triggered automatically.Perform Releaseworkflow can also be triggered manually now.