ci: restrict specific workflows to the upstream repository#28778
ci: restrict specific workflows to the upstream repository#28778nimdrak wants to merge 1 commit into
Conversation
35aa661 to
148c2fc
Compare
|
[NON-BLOCKING] Packit jobs failed. @containers/packit-build please check. Everyone else, feel free to ignore. |
|
The failed tests are not related with this PR |
Luap99
left a comment
There was a problem hiding this comment.
We move the repo soon, lets wait with this until we have the new nmae as we need to change the name again otherwise in a follow up commit.
|
@Luap99 Got it, thanks for letting me know! |
|
The new repo location will be |
|
Could you confirm if the following should also be updated to the new podman-container-tools organization? Related Repositories:
Team Mentions:
|
That will be
I would not bother with this right now, just update the conditions you want to skip the runs, we take care of the release automation once we are there |
|
Great idea! I think the release-pipeline-validation.yml also requires secrets. |
148c2fc to
c8cad6d
Compare
Thanks. Got it. I updated the conditions only. Please check it.
You're right. I updated too. Thanks. |
c8cad6d to
f5eff36
Compare
Many GitHub Actions workflows currently trigger on user forks, leading to unnecessary CI resource consumption, unwanted bot behavior, and inevitable failures. This commit restricts these specific workflows to only run on the primary `containers/podman` repository. The restricted workflows fall into two main categories: 1. Require Custom Upstream Secrets: Workflows like `release`, `mac-pkg`, `cherry-pick`, and `dev-bump` rely on secrets (e.g., Apple/Azure certs, PODMANBOT_TOKEN, ACTION_MAIL_*) that are unavailable in forks. 2. Manage Upstream Tracker State: Workflows like `assign`, `stale`, and `labeler` are intended strictly for managing the primary project's issues and PRs. Running them on personal forks creates unwanted noise. Additionally, refactored several complex `if` conditions using YAML multi-line strings (`|`) to maintain and improve readability. Signed-off-by: Byounguk Lee <nimdrak@gmail.com>
f5eff36 to
7fc96b5
Compare
That seems a really strange validation error, I mean the script is in the git tree so what happened here? btw I recommend to not blindly repush to retrigger CI, we can rerun tests as needed and I would have liked to see if this was a flake or not |
|
Ah, sorry about the repush! I actually pushed again because I thought I messed up my rebase, not just to retrigger the CI. But I'll keep your advice in mind for next time. |
Regarding the missing script error, I think I found the cause. Initially, instead of doing a proper rebase, I manually deleted. Because my branch was still outdated, it didn't have ./hack/ci/make-and-check-size.sh yet, which is what broke the CI. However, I've done a proper rebase now, and it looks like the issue is gone. Sorry for the confusion! |
What does this PR do?
Fixed #28757
All GitHub workflows fail because they require secrets. The only exception is
zizmor.yaml, which runs a static analysis security check on GitHub Actions.Here is the corrected list of workflows that should be restricted to upstream(
containers/podman), categorized by why they will fail or act improperly in a fork:They rely on secrets that are only available in the upstream repository:
check_cirrus_cron.yml: UsesACTION_MAIL_*secrets for alerting.cherry-pick.yml: UsesCHERRY_PICK_TOKENto automate pushing to release branches.dev-bump.yml: UsesPODMANBOT_TOKENto push version bumps.first_contrib_cert_generator.yml: UsesCERTIFICATES_REPO_TOKENto commit to the external contributor certificates repo.issue_pr_lock.yml: UsesSTALE_LOCKING_APP_PRIVATE_KEYandACTION_MAIL_*secrets.machine-os-pr.yml: UsesPODMANBOT_TOKENto push updates.release.yml: The primary release pipeline; requires Apple signing (MACOS_*), Azure signing (AZ_*),ACTION_MAIL_*, andPODMANBOT_TOKEN.update-podmanio.yml: UsesPODMANBOT_TOKENto push updates to thecontainers/podman.iorepository.These workflows require write permissions to automatically manage issues, labels, and assignments.
assign.yml: Self-assigns issues.issue-labeler.yml: Automatically applies labels to new issues.labeler.yml: Automatically applies labels to PRs based on changed file paths.needs-info-labeler.yaml: Automates comments when theneeds-infolabel is added.stale.yml: Marks older issues and PRs as stale and closes them.➕ Additional Details
I refactored several complex
ifconditions using YAML multi-line strings (|) to improve readability and maintainability.Does this PR introduce a user-facing change?