summaryrefslogtreecommitdiff
path: root/.github/workflows
Commit message (Collapse)AuthorAge
* Use more recent `stale` release...Stuart Shelton2021-05-16
| | | | | | … 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>
* Fix variable reference typo. in multi-arch image actionChris Evich2021-05-03
| | | | | | | | | | | | 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>
* Fix multi-arch image workflow typoChris Evich2021-04-30
| | | | Signed-off-by: Chris Evich <cevich@redhat.com>
* Update container image docs + fix unstable executionChris Evich2021-04-29
| | | | | | | | | | | | | | | | 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>
* Fix logic for pushing stable multi-arch imagesChris Evich2021-04-26
| | | | | | | | | | 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>
* Several multi-arch image build/push fixesChris Evich2021-04-23
| | | | | | | | | | | | * Fix not setting `$VERSION` before reference * Reduce need for "syntax-hilighting workaround` comment. Simplify context-expressions -> simple env. var. referenmces * Fix pushing quay.io/containers/podman:master twice ('upstream' and 'testing' matrix items) * Throw error on unknown/unsupported matrix items * Improve readability of setting multi-line `$LABELS` value. Signed-off-by: Chris Evich <cevich@redhat.com>
* Add github-action workflow to build/push multi-archChris Evich2021-04-22
| | | | | | | | 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>
* Cirrus: Send cirrus-cron report e-mail to list.Chris Evich2021-02-08
| | | | | | | | | 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>
* Github-Actions: Send e-mail on Cirrus cron failureChris Evich2020-11-18
| | | | | | | | | | | | | | | 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>
* Yet another iteration on PR title pluginEd Santiago2020-10-26
| | | | | | | | | 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>
* pr update action: fix errors on master branchValentin Rothberg2020-10-26
| | | | | | | | | | | | 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 GitHub action to add non-main branch to PR titleValentin Rothberg2020-10-25
| | | | | | | | | | | | | | | | 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 stale botValentin Rothberg2020-09-22
| | | | | | | | | | | | | | 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>
* github stale workflow: rephrase and bump close timeValentin Rothberg2020-01-07
| | | | | | | | 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>
* stale action: add exempt-issue-labelValentin Rothberg2019-10-30
| | | | | | | Without the label, issues would be closed regardless of the "do-not-close" label. Signed-off-by: Valentin Rothberg <rothberg@redhat.com>
* GitHub stale actionValentin Rothberg2019-10-28
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>