Allow build-* workflows to be ran on demand on any git ref
#11221
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
✅ All tests successful. No failed tests found. Additional details and impacted files@@ Coverage Diff @@
## main #11221 +/- ##
==========================================
+ Coverage 35.07% 35.16% +0.09%
==========================================
Files 2710 2719 +9
Lines 84550 84926 +376
Branches 16070 16158 +88
==========================================
+ Hits 29656 29868 +212
- Misses 53923 54080 +157
- Partials 971 978 +7 ☔ View full report in Codecov by Sentry. |
|
New Issues
Fixed Issues
|
|
Looks like some builds are failing because a few workflows run twice (for example, 
The easy solution is to enable |
|
Semi-successful run: https://github.com/bitwarden/clients/actions/runs/11017250075/job/30595187922 Not sure what to make of that error. Any ideas? @withinfocus |
|
Closing this for now, but we'll continue to look into enabling easier workflow execution for community PRs. Likely by removing or delaying access to secrets for workflows. Thanks again @Tyrrrz for looking into this! |
🎟️ Tracking
https://bitwarden.atlassian.net/browse/PM-12022
📔 Objective
build-*.ymlworkflows to run on manual dispatch. Add an input parameter calledcheckout_refthat allows the actor to manually specify any commit hash, tag, or branch to run the workflow against. This can be used with a commit hash from a 3rd-party fork.build-all.ymlworkflow that can run on manual dispatch. This workflow simply calls all otherbuild-*.ymlworkflows.With this approach, instead of going through the lengthy and wasteful process of rehoming the community PR branch via a Clone PR, a Bitwarden developer can simply manually run the build workflows (all or just a few specific ones) on the community PR branch. Then, they can include the link to the corresponding artifacts in the QA testing notes.
Because the trigger of the workflow is not a
pull_requestevent, but aworkflow_dispatchevent, the corresponding run will have full access to secrets. While this is risky, it's not inherently any less secure than the current Clone PR process, which is just a messy workaround for doing the same thing -- triggering build workflows with elevated privileges on a PR branch from an outside fork.📸 Screenshots
(once this is merged, you will be able to do this from GitHub Web as well)
(as you can see, all jobs are running despite the target being a branch from an outside fork)
⏰ Reminders before review
🦮 Reviewer guidelines
:+1:) or similar for great changes:memo:) or ℹ️ (:information_source:) for notes or general info:question:) for questions:thinking:) or 💭 (:thought_balloon:) for more open inquiry that's not quite a confirmed issue and could potentially benefit from discussion:art:) for suggestions / improvements:x:) or:warning:) for more significant problems or concerns needing attention:seedling:) or ♻️ (:recycle:) for future improvements or indications of technical debt:pick:) for minor or nitpick changes