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>
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>
Followup on #19477
Remove commented out cirrus task for fcos image build with podman-next
and add 2 github actions: 1 for running a simple uni-arch image build
on every PR and another to actually build multiarch images and push to
quay after merge.
`podman --version` will also include git short sha for clarity.
[NO NEW TESTS NEEDED]
Signed-off-by: Lokesh Mandvekar <lsm5@fedoraproject.org>
Don't need this email as we have podman-monitor email listed wherever
relevant.
[NO NEW TESTS NEEDED]
Signed-off-by: Lokesh Mandvekar <lsm5@fedoraproject.org>
This commit limits the blast-radius should the workflow fail
catastrophically. It also instruments the workflow with a job-level
test-failure to trigger a notification mail. This commit should be
reverted once the workflow is deemed functional.
Signed-off-by: Chris Evich <cevich@redhat.com>
This may be helpful in case SHA comparison is needed w/ files elsewhere.
For example, the files uploaded to a github release page.
Signed-off-by: Chris Evich <cevich@redhat.com>
These are visible when running either job manually. Fix the windows
workflow by including a `v` prefix to an obviously fictitious version
number. For consistency, update the mac workflow text to match.
Signed-off-by: Chris Evich <cevich@redhat.com>
Neither `release` nor `workflow_dispatch` triggers may be tested inside
a PR context. The workflow steps always run from what's already
committed to `main`. Rather than waiting for a release to discover
some unforeseen workflow problem, allow manual runs to optionally skip
the release upload step (by default).
Also, update the windows workflow to store an artifact of the signed
build, and migrate away from the deprecated "set-output" command.
Signed-off-by: Chris Evich <cevich@redhat.com>
Having hard-coded versions burried under a hidden directory is ripe for
maintenance headaches. Use the latest 'stable' version, since this will
be "close enough" to what we test in CI.
Ref: https://github.com/containers/podman/discussions/19404
Signed-off-by: Chris Evich <cevich@redhat.com>
Create a new GitHub Action that builds and signs the Mac pkginstaller. The action also uploads the installers to the release, and updates the shasums file.
This action is triggered on release creation, but it can also be triggered manually via a workflow dispatch.
Signed-off-by: Ashley Cui <acui@redhat.com>
Due to a bad file-format design, if a cirrus-cron job happened to have a
name w/ spaces, the generated e-mail text would be broken. For example:
```
Cron build 'VM' Failed: https://cirrus-ci.com/build/Image Maintenance
5630822628196352
```
Fix this by flipping the field-order in an intermediate file, so the
build ID comes first, then the job name. This makes it much easier for
`read` to process, since all words will be stored into the final
variable (now the job name).
Also change all variables that reference this intermediate file such
that they continue to reflect the expected field order. Update script
tests and add a new test to confirm expected file processing and output.
Signed-off-by: Chris Evich <cevich@redhat.com>
