chore(ci/release): Re-factor fluent-operator release process#1950
chore(ci/release): Re-factor fluent-operator release process#1950joshuabaird wants to merge 13 commits intofluent:masterfrom
Conversation
Signed-off-by: Josh Baird <jbaird@galileo.io>
Signed-off-by: Josh Baird <jbaird@galileo.io>
Signed-off-by: Josh Baird <jbaird@galileo.io>
Signed-off-by: Josh Baird <jbaird@galileo.io>
Signed-off-by: Josh Baird <jbaird@galileo.io>
joshuabaird
changed the title
Signed-off-by: Josh Baird <jbaird@galileo.io>
Signed-off-by: Josh Baird <jbaird@galileo.io>
Signed-off-by: Josh Baird <jbaird@galileo.io>
| name: Lint PR Title | ||
|
|
||
| on: | ||
| pull_request_target: |
There was a problem hiding this comment.
This is always a concern so let's make sure we're secure with it - it's part of the recent supply chain attacks.
I think we should at least comment why it is required and the mitigations in place for future reviews/changes to ensure we do not open things up.
There was a problem hiding this comment.
Thanks for calling this out -- this is a valid concern.
One key thing here to call out is that this workflow is not checking out any code (eg, using actions/checkout) which is what allowed attacker-controlled code execution in the mentioned supply chain attacks.
I have attempted to harden this workflow a bit in 55357df:
- Added a comment about the need for
pull_request_targetand a warning against adding checkout functionality to the workflow - Removed the
synchronizetype since PR title changes only occur onopened,reopenedandeditedevents. Thesynchronizetype fires on every new commit push and is unnecessary for this use-case - Removed top-level permissions and only grant needed access at the job-level to prevent accidental inheritence
- Added a
CODEOWNERSso that only users who are "Admins" of this repo can modify files in the.github/directory
| required: false | ||
| type: string | ||
|
|
||
| permissions: |
There was a problem hiding this comment.
The docs suggest it needs issues: write as well so do we (and if not maybe indicate why)?
There was a problem hiding this comment.
From what I understand: release-please <4.0 did use "issues" to track the replace process but >=4.0 removed the issue-based workflow any only uses PRs/git tags for driving the release process.
| release-please: | ||
| runs-on: ubuntu-latest | ||
| steps: | ||
| - uses: googleapis/release-please-action@45996ed1f6d02564a971a2fa1b5860e934307cf7 # v5.0.0 |
There was a problem hiding this comment.
Thanks for this, had a hand crafted approach for our stuff so useful to know.
|
|
||
| ```shell | ||
| kubectl apply -f https://raw.githubusercontent.com/fluent/fluent-operator/release-3.7/manifests/setup/setup.yaml | ||
| kubectl apply -f https://github.com/fluent/fluent-operator/releases/latest/download/setup.yaml |
There was a problem hiding this comment.
Does this work now? It used to intercept and provide you with HTML if you did not use the raw endpoint
There was a problem hiding this comment.
Yeah - it looks like it does work now. I wonder if this recently changed. I do recall exactly what you're talking about.
|
Can we verify these run ok before merge as well with something like act? I hate the fact you cannot test new workflows properly until they are merged. It looks like we do not run actionlint or anything at the moment so we really should add that in too. |
Signed-off-by: Josh Baird <jbaird@galileo.io>
Signed-off-by: Josh Baird <jbaird@galileo.io>
Yeah - testing GHA is always cumbersome. Adding actionlint is a great idea. Will incorporate that into this PR as well. |
Signed-off-by: Josh Baird <jbaird@galileo.io>
2 participants
Fixes #1949.
TODO:
master