chore(ci): Only promote if possible #2721
Conversation
Signed-off-by: Josh Soref <2119212+jsoref@users.noreply.github.com>
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #2721 +/- ##
===========================================
+ Coverage 61.56% 74.62% +13.06%
===========================================
Files 53 73 +20
Lines 9002 11139 +2137
===========================================
+ Hits 5542 8313 +2771
+ Misses 3020 2191 -829
- Partials 440 635 +195 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
I am going another way in my own projects. My schedule jobs have the following if. if: vars.ENABLE_PROMOTEWell your proposal don't require cplee to add a variable, but it does cost / block at least one action minute for the User |
|
I've gone both ways in the past. I have no particular preference. My goal is smoothest adoption, and as you note this requires no additional work by the master repo owner. Since most act forks are going to be public and most forks won't have so many other repositories burning minutes, I think the 1 action minute isn't particularly expensive. That said, I'd be more than happy to use the vars approach if that's acceptable. |
LGTM. I leave this 100% to him, since he is effectively a required reviewer I also use your approach, but only in cases where the secret is merely desirable and not absolutely necessary for meaningful execution. |
| @@ -11,12 +11,19 @@ jobs: | |||
| environment: promote | |||
| steps: | |||
| - uses: actions/checkout@v4 | |||
| id: checkout | |||
| env: | |||
| has_promote_token: ${{ secrets.PROMOTE_TOKEN && '1' || '' }} | |||
There was a problem hiding this comment.
This was a nice trick. I learned something new. Thanks!
Without this, when people update
masterin forks with actions enabled, they get failures...