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>
It's nearly impossible for humans to tell semantic-version differences
by looking at a commit sha. Since all the actions in question come from
github, there's little security/safety benefit to using SHAs.
Signed-off-by: Chris Evich <cevich@redhat.com>
Fairly universally, the last Cirrus-Cron job is set to fire off at
22:22 UTC. However, the re-run of failed jobs GHA workflow was
scheduled for 22:05, meaning it will never re-run the last cirrus-cron
job should it fail.
Re-arrange the execution order so as to give plenty of time between the
last cirrus-cron job starting, the auto-re-run attempt, and the final
failure-check e-mail.
Signed-off-by: Chris Evich <cevich@redhat.com>
The checkout action by default, clones the current repository. However,
since this workflow is re-used by other repos, and it calls scripts in
the podman repo, those calls will all fail. Fix this by hard-coding the
podman repo.
Ref: https://github.com/actions/checkout
Signed-off-by: Chris Evich <cevich@redhat.com>
It's possible to reuse a GHA workflow from another repo with minimal
YAML. However there are certain requirements, like spelling out all the
required secret values. Also any mention of `ACTIONS_STEP_DEBUG` will
cause failures and must be removed.
As usual, there's no convenient way to test these changes without pushing
to a `main` branch somewhere that also has all the proper secrets
configured. However, I did pattern these changes off of a working setup
in buildah:
fd2d05c0a7/.github/workflows/check_cirrus_cron.yml
Signed-off-by: Chris Evich <cevich@redhat.com>
Because in github-actions, setting a secret variable isn't enough. You
ALSO have to set it again in your YAML. I guess it's assumed in the
name of "security" that the person with access to secrets, might not
also have access to update YAML. Crazy!
Also, while I'm at it. Bump up the execution schedule WRT the
check_cirrus_cron workflow - this will give re-run jobs more time to
complete.
Signed-off-by: Chris Evich <cevich@redhat.com>
This component was recently migrated from being inline, into a dedicated
script file. This was necessary for testing. However, it's hard to
test the actual github-actions workflow YAML, and there was a typo. Fix
the reference to the script filename missing the `.sh` extension.
Ref: https://github.com/containers/podman/pull/16414
Signed-off-by: Chris Evich <cevich@redhat.com>
Lack of proper testing possibility for github actions and lack of
script-testing by me, allowed several flaws through into 'main'. Fix
the problems and manually test the scripts to make sure they're working.
Note: Also revert the stupid SHA-based action-pinning back to normal,
human-readable version numbers. The value of using SHAs in the name of
improved "security" is real, but the value of human-readability and
ease of maintenance is greater.
Signed-off-by: Chris Evich <cevich@redhat.com>
With a seemingly ever growing list of cirrus-cron jobs running on
release branches, there are bound to be some hiccups. Sometimes a lot
of them. Normally any failures require a human to eyeball the logs
and/or manually re-run the job to see if it was simply a flake. This
doesn't take long, but can be distracting and compounds over time.
Attempt to alleviate some maintainer burden by using a new github action
workflow to perform **one** automatic re-run on any failed builds. This
task is scheduled an hour prior to a second failure check, and generation
of notification e-mail for review.
Note: If there are no failures, due to the auto. re-run or luck, no
e-mail is generated. If this proves useful in this repo, I intend to
re-use this workflow for other repo's cirrus-cron jobs.
Signed-off-by: Chris Evich <cevich@redhat.com>
Inline scripts make github-action workflow YAML harder to read/maintain.
Relocate the e-mail formation script to a dedicated file. This also
permits better input-validation and re-use of a common `err()` function.
Signed-off-by: Chris Evich <cevich@redhat.com>
This workflow was originally crafted to be (somehow) reused with
different scripts. That never happened and the extra indirection is
confusing and hard to maintain. Remove it.
Signed-off-by: Chris Evich <cevich@redhat.com>
Github-actions for large/complex tasks is hard to read and maintain.
Reimplement the multi-arch image build workflow into a set of bash
scripts that use all native contrainer-org tooling. This requires
a special VM image setup with emulation to build foreign architectures.
It also requires renaming the `helloimage` directory, because the build
script uses the directory name in the image FQIN.
Signed-off-by: Chris Evich <cevich@redhat.com>
We get a lot of issues for podman-remote on macos. Since the fact that
this is a remote client is often overlooked by us lets add windows, macos
and remote label automatically based on a regex which should match the
output of podman version.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
The `body` string value must be quoted because it contains a colon.
Also fix an incorrect URL substitution reference in error-notice e-mail
body text.
(In my defense...testing this workflow is basically impractical without
merging it)
Signed-off-by: Chris Evich <cevich@redhat.com>
This job is designed to be silent when Cirrus-cron executions pass.
Unless specifically instructed, the workflow itself will also remain
silent if there's an error. Fix this by catching workflow errors and
sending a notification e-mail containing a link to the failed run. This
also requires listing the recipient addresses directly in the workflow.
Otherwise (as previouslly implemented) the value would not be retrieved
if/when any previous step raised an error.
**Note**: Due to the way this workflow is implemented, there is no way
easy way to test it other than directly on the `main` repo. branch.
Signed-off-by: Chris Evich <cevich@redhat.com>
This duplicates the change from
https://github.com/containers/skopeo/pull/1379
Since this workflow is duplicated across three repositories, maintaining
changes becomes onerous if the item contents vary between
implementations in any way. Improve this situation by encoding the
repository-specific details into env. vars. then referencing those vars
throughout. This way, a meaningful diff can be worked with to compare
the contents across repositories.
Also included are abstractions for the specific command used to obtain
the project version, and needed details for filtering the output. Both
of these vary across the Buildah, Skopeo, and Podman repos.
NOTE: This change requires the names of two github action secrets
to be updated: PODMAN_QUAY_USERNAME -> REPONAME_QUAY_USERNAME
(and *PASSWORD).
Signed-off-by: Chris Evich <cevich@redhat.com>
The master->main rename broke this. Also update the runtime along with
a comment w/ link to the actual job definitions.
Signed-off-by: Chris Evich <cevich@redhat.com>
A suspected recent change in docker (in github-actions Ubuntu
environment) results in a error:
```
cannot clone: Operation not permitted
Error: cannot re-exec process
```
Fix this by using podman to execute the container instead of docker.
Signed-off-by: Chris Evich <cevich@redhat.com>
Besides adding ***BIG FAT WARNING*** this commit updates the
containers-repo. logic to only (and properly) handle the `stable` image
(both version and `latest` tags). This change was already discussed at
length with @TomSweeneyRedHat.
Signed-off-by: Chris Evich <cevich@redhat.com>
… as currently with `v1`, `remove-stale-when-updated` is set but isn't causing labels to be updated when comments are added.
Signed-off-by: Stuart Shelton <stuart@shelton.me>
Bug introduced by #10150
Also, in case of failure of one matrix-leg, do not terminate execution
of all others. There are many reasons why an item could fail (i.e.
temporary networking problem). Since the job runs periodically,
we can simply allow the subsequent run to cover for any missed images
pushes due to sporadic job failures.
Signed-off-by: Chris Evich <cevich@redhat.com>
