This workflow is used and called by buildah and skopeo, however due this
new if it will just get skipped there as the context on a action reuse
will still be set to the proper repo which calls the action.
The point of this new if from commit 32f987fc8c
("ci: restrict specific workflows to the upstream repository")
was to avoid running our actions on forks where they will fail due to
missing secrets, etc...
So by limiting the scope to our org here we can reuse it from buildah
and skopeo and still prevent it running on forks from users.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
Using the app id is deprecated, also so far since the repo move this
workflow failed all the time as the github app was not in the new org.
I created a new app for this and set the right vars.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
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>
Frequent but intermittently, the stale issue and PR locking workflow
generates the error:
```
You have exceeded a secondary rate limit. Please wait a few minutes
before you try again. If you reach out to GitHub Support for help,
please include the request ID XYZ
```
According to upstream `dessant/lock-threads` issue 48, this seems to be
coming from the GitHub side (bug/feature/limitation), since the action
uses an official github API rate-limiting library. It's unlikely related
to which style/syntax of github token is used, nor if the action is
executed concurrently across multiple repos.
According to the rate-limiting docs:
https://docs.github.com/en/rest/using-the-rest-api/rate-limits-for-the-rest-api?apiVersion=2022-11-28#about-secondary-rate-limits
it's possible the issue is caused due to an unknown aspect of the clause:
```
These secondary rate limits are subject to change without notice. You
may also encounter a secondary rate limit for undisclosed reasons.
```
The same docs indicate Github Apps have enhanced rate-limits which
scale with the org's repo count. Attempt to fix the intermittent
failures by making use of a new, dedicated, org-specific, private "Stale
Locking App" I recently created. This requires the addition of a new
action to the workflow that obtains a short-lived token for passing to
lock-threads.
Note: Because both `vars.STALE_LOCKING_APP_ID` and
`secrets.STALE_LOCKING_APP_PRIVATE_KEY` are defined at the
containers-organization level, the Buildah and Skopeo re-use
of this workflow should continue to function normally w/o change.
Signed-off-by: Chris Evich <cevich@redhat.com>
A simple file rename quickly broke the same workflow in both the Buildah
and Skopeo repos. Add a big-fat warning comment to prevent this from
happening again.
Signed-off-by: Chris Evich <cevich@redhat.com>
Periodically, the discussion-lock workflow throws the error: `Resource
not accessible by integration`
This was identified in the
[upstream](https://github.com/dessant/lock-threads)
issue 47, as caused by a version-5 change that adds support for
management of discussions but requires additional permissions
and possibly settings. Given the low notification traffic from
discussions, old discussions may remain valid for a long while, and are
a useful community-interface: Disable management of discussions.
Signed-off-by: Chris Evich <cevich@redhat.com>
2024-04-09 11:19:08 -04:00
Renamed from .github/workflows/discussion_lock.yml (Browse further)
