-
Notifications
You must be signed in to change notification settings - Fork 22
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
chore(ci): rename GUI PR GHA to "release" #3047
Conversation
✅ Deploy Preview for kuma-gui ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
5b34c3b
to
a89f886
Compare
0ed3cda
to
811916e
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Notes:
@lahabana showed me a button in the GH UI that does exactly what this PR does 😆 , so a lot of this PR is no longer needed. There are some bits here that I'd like to keep, mostly the renaming of "Create GUI PR" to "Release". We'd also like to improve the "release" PRs to include more changelog information. For the moment I'm going to put this back into draft. While I re-jiggle this about a bit. |
811916e
to
f00273a
Compare
Signed-off-by: John Cowen <[email protected]>
f00273a
to
2b905d1
Compare
This PR changed our "Create GUI PR" workflow:
release.yaml
/Build and release to kumahq/kuma
because we are releasing the GUI to the binary/kuma. "Create GUI PR" sounds like I am creating a PR onkumahq/kuma-gui
2. Added arepository-data
job that fetches all "topics" from the repository3. Uses therepository-data
output to look for aauto-release
"topic" which when present (as it is currently) performs a "release" as before.I plan on merging this with theauto-release
"topic" applied to prove it works (validate the PR is made). I will then remove theauto-release
topic temporarily.Notes:I "think" I can't access the secrets in a run because I'm PRing from a forked PR, hence will currently fail until this is onmaster
. I would level a better way to test this out (and GH Actions as a whole really) edit: I confirmed offline that my guess here is right.In this PR we have two calls to get the GH token. One during the actual "release" and one to have permissions to access the repo topics. I plan on reusing the one in therepository-data
job across the entire workflow once this PR is merged and we know it works as expected 🤞edit: See comment below, but TLDR; this PR now pretty much just renames the workflow action:
release.yaml
/Build and release to kumahq/kuma
because we are releasing the GUI to the binary/kuma. "Create GUI PR" sounds like I am creating a PR onkumahq/kuma-gui