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>
Some issues reported in the podman github project contains a
question instead of a bug report or feature request. Make it
easier for users to find a place to ask questions.
Signed-off-by: Erik Sjölund <erik.sjolund@gmail.com>
The relative link seems flakey: depending where you're creating the issue this may not take you to the right place.
For example, from https://github.com/containers/podman/issues/new it takes you to https://github.com/containers/podman/README.md, which does not exist.
To fix this, I've replaced it with an absolute link to the README for people to find the version easily. Other places in the same issue template use absolute paths to places in the repo e.g. the wiki, so I think this is acceptable.
Signed-off-by: Adam Jones <domdomegg+git@gmail.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>
Mention that using `su` does not establish a proper login session
required for running rootless Podman. It is a common and reoccurring
issue. Mentioning that in the issue template may guide users into
resolving the issue before opening an issue.
Signed-off-by: Valentin Rothberg <vrothberg@redhat.com>
Fixes: #18139
Removing the Dependabot configuration file is a required prerequisite to
stopping it from opening update PRs. Once this commit is merged, the
`Dependabot security updates` repo. setting may also be disabled. Note:
The `Dependabot alerts` setting should remain enabled, this provides
security-data to renovate for opening important vulnerability fix PRs.
Signed-off-by: Chris Evich <cevich@redhat.com>
There are days when I really, really, really hate GNU. Remember
when someone decided that 'head -1' would no longer work, and
that it was OK to break an infinite number of legacy production
scripts? Someone now decided that egrep/fgrep are deprecated,
and our CI logs (especially pr-should-include-tests) are now
filled with hundreds of warning lines, making it difficult
to find actual errors.
I expect that those warnings will be removed quickly after
furious community backlash, just like the 'head -1' fiasco
was quietly reverted, but ITM the warnings are annoying
so I capitulate.
Signed-off-by: Ed Santiago <santiago@redhat.com>
It's desireable for renovate to mange `test/tools/go.mod` however, the
default ignorePaths is:
```
"ignorePaths": [
"**/node_modules/**",
"**/bower_components/**",
"**/vendor/**",
"**/examples/**",
"**/__tests__/**",
"**/test/**",
"**/tests/**",
"**/__fixtures__/**"
]
```
Update this list to only include `vendor` and `docs`.
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>
We already label the issue anyway and this results in reports without
an actual title so remove it. This leaves more space for an actual
useful title.
ref: https://github.com/containers/podman/discussions/17431
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
A semantic change to a Cirrus-CI GraphQL API parameter caused a
unit-test to fail (as it should have) with the error:
```
Query result did not pass filter '.data.ownerRepository.cronSettings':
'{"data":{"ownerRepository":null}}'
```
As per Cirrus-support, a change was introduced in schema affecting certain
fields that were incorrectly marked Nullable. They indicated the `platform`
field was set incorrectly, and should use the value `github`.
* Fix the platform field's value to `github` instead of `LINUX`.
* Change the unit-test to only execute as part of the 'main' cirrus-cron
job so it cannot impact PRs.
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>
Adding "Bug Report" and "Feature Request" templates, this will
help with filing the tickets and also finding the information
once filed.
Signed-off-by: Mohan Boddu <mboddu@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>
Just a quick little addition to provide the command to get the package
info from brew for those who might not know.
Signed-off-by: Kirk Bater <kirk.bater@gmail.com>
Belated followup to #11829: use github labeler workflow[1] to
auto-add 'kind/api-change' label to PRs in which files are
touched under pkg/api
[1] https://github.com/actions/labeler
Signed-off-by: Ed Santiago <santiago@redhat.com>
Previously the reply JSON was examined for the literal presence of the
string 'error'. This was intended to catch server or query errors and
the like. However it's not a sound design as valid/legitimate contents
could potentially contain the string. Fix this by using the `-e` option
to `jq`, with a filter that should always result in a non-empty/null
match. If this fails or returns null for some reason, then it's safe to
throw a real error code & message.
Signed-off-by: Chris Evich <cevich@redhat.com>
