This change will minimize renovate PR's.
Checkout is an action maintained by GitHub, so using the latest v4 action shouldn't have stability consequences.
Signed-off-by: Ashley Cui <acui@redhat.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>
Add a new GitHub Action that builds and uploads release artifacts. This action is triggered by publishing a release on GitHub. The action will only build if the specfic artifact is missing.
This action also triggers the Windows installer action, since the Windows installer action depends on an uploaded artifact.
Note that the action runs on ubuntu-22.04
Signed-off-by: Ashley Cui <acui@redhat.com>
We temporarily installed wixtoolset using chocolatey, when 3.14 wasn't in GHA yet. Now it's there by default, so remove the install. This prevents the downgrade error. Note: If we change the minir version of WiX that we use, then we may need to install wix again. But for now, removing this step will allow us to use the latest 3.14 patch.
Signed-off-by: Ashley Cui <acui@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>
Introduce a new GitHub action that will update Podman.io to the newest version of Podman. This action will run on a release being published to GitHub, or by clicking the run workflow button on GitHub. The action will check if the release version is higher than the current version on the website, and open a PR to update the version if a PR does not already exist. The commit will be signed off by the user who triggered the action, so whoever creates the release or presses the run workflow button. The PR will be opened by the podmanbot GitHub account.
Signed-off-by: Ashley Cui <acui@redhat.com>
Ref:
https://github.com/containers/podman/pull/21570#issuecomment-1935709148
This tool is really intended/best used from git pre-commit on developers
local machines, to prevent addition of secret leaks. When used as a
check against PRs, it tends to turn up more false-positives than helpful
warnings. There's no good way to fix this, and maintaining the scanner
is an additional burden. Rather than continue struggling to improve/fix
the situation, let's just remove the tool entirely.
Signed-off-by: Chris Evich <cevich@redhat.com>
I have no idea why the `event_name` != `github.event.action`, but in
this case it doesn't. For consistency with other related condition
checks, use the later over the former.
Signed-off-by: Chris Evich <cevich@redhat.com>
Previously when a leak was detected under any circumstance, the workflow
would splat out a giant wall of gray, unreadable git-log text. This often
enormous text might contain, somewhere, possibly, maybe, a little tiny
snippet of code that leaks a secret.
Improve the situation greatly by providing easy-to-use URLs that covers
the relevant changes based on the triggering context (new pr, force-push,
or merge). Store the former (often) giant git-log output into a file
and stuff it into the artifacts in case it's ever useful.
Signed-off-by: Chris Evich <cevich@redhat.com>
Commit ca66a90b87 was merged without fixing the config. Please read
changelogs before merging renovate PRs, especially when it is a major
version bump.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
The podman in `ubuntu-latest` environment apparently is too old to
support `--userns=keep-id:uid=1000,gid=1000`. Employ workaround in GHA
workflow and in `prebuild.sh` check.
Signed-off-by: Chris Evich <cevich@redhat.com>
As an effort to catch potential secrets and/or credential leaks, add a
github-actions workflow which is untouchable in a PR context.
To additionally guard against accidents, also check recent branch
history. This is especially important on newly created
release-branches, which may begin with content from who-knows-where.
Finally, since the new workflow bypasses PR-level changes to the scanner
config and base-line. Add a Cirrus-CI invocation of the scanning tool
to help catch tool-breaking changes from being merged.
Signed-off-by: Chris Evich <cevich@redhat.com>
`wait-for-copr` is still very flaky and has failed more often than not.
Ref: https://github.com/fedora-copr/copr/issues/2819
This change to the fcos GHA will allow nightly builds pulling in
whatever packages exist on podman-next at that time without depending on
wait-for-copr.
The commit id will still be recorded in podman version as well as the
image tag, so auditing is not affected with this change.
[NO NEW TESTS NEEDED]
Signed-off-by: Lokesh Mandvekar <lsm5@fedoraproject.org>
The closed issue & PR lock is working fine, but it has a built-in
50-item limit. The limit is not configurable. Since there are
tens-of-thousands of issues/prs to go through, 50-per-day could take
almost a year. Speed things up 24x by running the job every hour
instead of daily.
Signed-off-by: Chris Evich <cevich@redhat.com>
