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>
Update the order of image documentation to be from most to least stable.
Similarly, avoid depending on execution of upstream podman, when
building/pushing. It's easily possible for this build to function but
execution to fail due to some partially implemented feature.
Also, ensure images tagged `latest` are pushed for every matrix
item. For 'upstream' and 'testing', this replaces use of the
'master' tag.
Lastly, update workflow comments and split the 'podman' and 'containers'
FQIN steps and outputs to improve readability.
Signed-off-by: Chris Evich <cevich@redhat.com>
The intention is to only push an image if there is ***NOT*** an existing
tag. The original logic for this condition was inverted.
Also, improve radability of the `{container,podman}_push=true`
statements.
Signed-off-by: Chris Evich <cevich@redhat.com>
This borrows very heavily from the work done for buildah by @barthy1 -
Yulia Gaponenko <yulia.gaponenko1@de.ibm.com>. Some changes to code and
comments made for clarity and specificity.
Signed-off-by: Chris Evich <cevich@redhat.com>
This mailing-list was established to allow people to sub/unsub from
automated notifications. Add it to the list of destinations picked up
by the Github Actions workflow
`.github/workflows/check_cirrus_cron.yml`.
Signed-off-by: Chris Evich <cevich@redhat.com>
This repository has a number of automaticly triggered branch-level
testing enabled. However, other than remembering to go look at a
specific WebUI, there is no way for anybody to notice if/when these jobs
fail.
This commit introduces a github-action workflow which runs periodically,
checking for failed cron-triggered Cirrus-CI jobs. When it finds any, it
formats a simple report for e-mail delivery. The list of destination
addresses is configurable at any time by merging changes to a
simple CSV file.
Signed-off-by: Chris Evich <cevich@redhat.com>
PR #8147 made things worse: it's not valid YAML. This at
least is valid YAML. I have no idea if it yields the
desired result, and we won't even know until it gets
merged, but at least it won't cause fatal syntax errors.
Signed-off-by: Ed Santiago <santiago@redhat.com>
The action fails on the master branch as the regex does not match.
The error in this scenario is unfortunate and not of much value as
we do not want to change PR titles on the master branch.
To fix it, entirely disable the action on the master branch which
in restrospective may be a better approach as we do not fire off the
action.
Signed-off-by: Valentin Rothberg <rothberg@redhat.com>
Add a GitHub action to add the name of the target branch as prefix to
the title of a pull request. It is easy to miss the target of a given
pull request which has already caused issues of commits going into
non-main branches without intention.
We have already used this action on the `v2.0.5-rhel` branch with
limited success. Fortunately, the upstream implemented our feature
request to support adding the _target_ branch name (rather than the
source) to the PR title, which is what we need.
Any non-main branch from this commit forward will now be clearly marked.
Signed-off-by: Valentin Rothberg <rothberg@redhat.com>
Update the GitHub action to mark issues and PRs as stale. There are a
couple of useful features, most importantly, the bot will remove the
stale label from issues as soon as there's either an activity or a
comment.
This reduces some manual overhead: the stale bot will only drop a
comment on issues and PRs that are not marked as stale. Hence, as we
appreciated the reminders, we had to manually remove the label which
should now turn into campfire tales.
Signed-off-by: Valentin Rothberg <rothberg@redhat.com>
Rephrase the stale message to be friendlier and bump the closing time to
365 days. The docs of the stale workflow do not indicate whether we can
not close, so a limit of 365 days seems fair.
Signed-off-by: Valentin Rothberg <rothberg@redhat.com>
Add a GitHub action to mark issues and PRs as stale and
to eventually close them after a grace period.
Signed-off-by: Valentin Rothberg <rothberg@redhat.com>
