Skip to content
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): Only promote if possible #2721

Merged
merged 2 commits into from
Apr 5, 2025
Merged

Conversation

jsoref
Copy link
Contributor

@jsoref jsoref commented Apr 1, 2025

Without this, when people update master in forks with actions enabled, they get failures...

Signed-off-by: Josh Soref <2119212+jsoref@users.noreply.github.com>
Copy link

codecov bot commented Apr 1, 2025

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 74.62%. Comparing base (5a80a04) to head (4ea2578).
Report is 197 commits behind head on master.

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.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

@ChristopherHX
Copy link
Contributor

I am going another way in my own projects. My schedule jobs have the following if.

if: vars.ENABLE_PROMOTE

Well your proposal don't require cplee to add a variable, but it does cost / block at least one action minute for the User

@jsoref
Copy link
Contributor Author

jsoref commented Apr 1, 2025

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.

@ChristopherHX
Copy link
Contributor

the master repo owner

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.

@mergify mergify bot merged commit 460ca18 into nektos:master Apr 5, 2025
12 checks passed
@jsoref jsoref deleted the maybe-promote branch April 6, 2025 01:04
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants