This reverts commit fb9ef0dda0041cc34246f395991bac4e1220d9fe.
Use latest stable go to build release artifacts.
Signed-off-by: Ashley Cui <acui@redhat.com>
Adds the build of the arm64 windows installer as part of the release
GitHub workflow.
When a Windows installer is uploaded to the GitHub release, it is named
consistently with the macOS one:
`podman-installer-windows-${GOARCH}.exe`
Signed-off-by: Mario Loriedo <mario.loriedo@gmail.com>
Create GitHub action to automatically bump to a -dev version after a release is tagged.
On a branch:
- The bump will always be a z bump on branches
- If the bump is to an RC, then the bump will be back down to dev (ie, 9.9.0-rc1 to 9.9.0-dev)
- If the bump is not an RC, the bump wil be up to dev (ie, 9.9.0 to 9.9.1-dev)
On main:
- If the X.Y version on main is smaller than the X.Y on the release tag, this action will open a PR to bump the version on main to the release tag's X.Y+1
- Major version (X) dev bumps will still need to be manual
Signed-off-by: Ashley Cui <acui@redhat.com>
When a reviewer of an issue determines that an issue is incompleted, a
`needs-info` label can be added to the issue. This will trigger a GH
action with an automated response. The reviewer should also have told
the user what is needed or asked a question. Also, we have no automated
way to remove the label when a response is provided, so this still needs
to be managed.
Signed-off-by: Brent Baude <bbaude@redhat.com>
When we do a release, we need to ensure that machine images are built before the release PR can merge.
This GitHub action is triggered on version bumps, waits for our COPR builds to finish, and then opens a PR on the podman-machine-os repo to build the required machine-os images there. Note that dev bumps, unless on main, will not open a PR
Signed-off-by: Ashley Cui <acui@redhat.com>
As pointed out in buildah[1] the action is broken in bad ways where it can
trigger 1000+ rerun wasting our cloud resources.
Get rid of it for now until we find something better or can properly
identify and fix the root cause.
[1] https://github.com/containers/buildah/issues/6035
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
Automatically generate our GitHub release.
This GitHub action is traggered on a tag push, or manually. After a the trigger, all artifacts are built, including linux, mac, and windows installers. After everything is built, the release is automatically generated on our GitHub, and an email notification is sent out.
Our old actions are marked deprecated, and now can only be triggered manually. Leave them as-is otherwise, as a backup, so we have a tried-and-tested way of generating images, just in case this new action goes wrong.
Signed-off-by: Ashley Cui <acui@redhat.com>
It is flaking[1] from time to time on PRs and doesn't really add value
because noone is actually chaing the Containerfile. The task on main
that build a image based of main still exists as per Lokesh
podman-dekstop uses it for testing. In the near term we will get proper
builds in the podman-machine-os repo so this other workflow can
hopefully removed altogether.
[1] https://github.com/containers/podman/actions/runs/10618524888/job/29433963845?pr=23807
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
Restore behavior for using uploaded zp file to generate the windows installer. This ensures that actions can always build and sign the installer, no matter how old the release, provided a .zip.
Signed-off-by: Ashley Cui <acui@redhat.com>
The chocolatey tool that was fetching us wix v3 can no longer be used to
fetch wix v4+ so we had to switch to dotnet to fetch the latest wix.
This commit builds the installer with wix v5.
wix v5 is installed via the `dotnet` tool in the windows image itself
at https://github.com/containers/automation_images/pull/354.
Going forward, the `dotnet` tool will also be used to build the installer.
In the process, the wix v3 files were converted to wix v4+ using `wix
convert` followed by manual modifications along with switch to wixproj
builds with dotnet.
The GitHub Action to upload windows installer now builds the installer
using winmake.ps1.
Contributions from Mario Loriedo:
- bundle setup update to wix5
- updates to build and release process scripts
Ref: https://github.com/lsm5/podman/pull/3
- small fixes to windows installer theme
Ref: https://github.com/lsm5/podman/pull/4
- Better win-installer sidebar logo
Ref: https://github.com/lsm5/podman/pull/5
Resolves: RUN-2055
Co-authored-by: Mario Loriedo <mario.loriedo@gmail.com>
Signed-off-by: Lokesh Mandvekar <lsm5@redhat.com>
Assist humans by indicating clearly whe a release announcement is
pertaining to a candidate. Otherwise, it's possible someone may
overlook the `-rcX` version suffix.
Also fix a quoting problem missed in testing.
Signed-off-by: Chris Evich <cevich@redhat.com>
Rather than manually crafting what ends up being nearly identical
release e-mails, do it automatically whenever a release is created.
Note: At the time of this commit, there is a possible race condition
with the `mac-pkg.yml` workflow, since it runs in parallel. It could
fail, or fail to complete prior to the e-mail content being generated.
This should be unlikely, if `release-artifacts.yml` goes through and
compiles every artifact, but it's not guaranteed.
Signed-off-by: Chris Evich <cevich@redhat.com>
There's a reasonable chance this workflow will be triggered by a human
(via `workflow_dispatch``), and a non-zero chance with an invalid
version number for which a release should not be created. Detect this
and provide a way for the operator to debug the source of the error.
Also fix some whitespace inconsistencies.
Signed-off-by: Chris Evich <cevich@redhat.com>
This change will minimize renovate PR's.
Checkout is an action maintained by GitHub, so using the latest v4 action shouldn't have stability consequences.
Signed-off-by: Ashley Cui <acui@redhat.com>
Frequent but intermittently, the stale issue and PR locking workflow
generates the error:
```
You have exceeded a secondary rate limit. Please wait a few minutes
before you try again. If you reach out to GitHub Support for help,
please include the request ID XYZ
```
According to upstream `dessant/lock-threads` issue 48, this seems to be
coming from the GitHub side (bug/feature/limitation), since the action
uses an official github API rate-limiting library. It's unlikely related
to which style/syntax of github token is used, nor if the action is
executed concurrently across multiple repos.
According to the rate-limiting docs:
https://docs.github.com/en/rest/using-the-rest-api/rate-limits-for-the-rest-api?apiVersion=2022-11-28#about-secondary-rate-limits
it's possible the issue is caused due to an unknown aspect of the clause:
```
These secondary rate limits are subject to change without notice. You
may also encounter a secondary rate limit for undisclosed reasons.
```
The same docs indicate Github Apps have enhanced rate-limits which
scale with the org's repo count. Attempt to fix the intermittent
failures by making use of a new, dedicated, org-specific, private "Stale
Locking App" I recently created. This requires the addition of a new
action to the workflow that obtains a short-lived token for passing to
lock-threads.
Note: Because both `vars.STALE_LOCKING_APP_ID` and
`secrets.STALE_LOCKING_APP_PRIVATE_KEY` are defined at the
containers-organization level, the Buildah and Skopeo re-use
of this workflow should continue to function normally w/o change.
Signed-off-by: Chris Evich <cevich@redhat.com>
Add a new GitHub Action that builds and uploads release artifacts. This action is triggered by publishing a release on GitHub. The action will only build if the specfic artifact is missing.
This action also triggers the Windows installer action, since the Windows installer action depends on an uploaded artifact.
Note that the action runs on ubuntu-22.04
Signed-off-by: Ashley Cui <acui@redhat.com>
We temporarily installed wixtoolset using chocolatey, when 3.14 wasn't in GHA yet. Now it's there by default, so remove the install. This prevents the downgrade error. Note: If we change the minir version of WiX that we use, then we may need to install wix again. But for now, removing this step will allow us to use the latest 3.14 patch.
Signed-off-by: Ashley Cui <acui@redhat.com>
A simple file rename quickly broke the same workflow in both the Buildah
and Skopeo repos. Add a big-fat warning comment to prevent this from
happening again.
Signed-off-by: Chris Evich <cevich@redhat.com>
Periodically, the discussion-lock workflow throws the error: `Resource
not accessible by integration`
This was identified in the
[upstream](https://github.com/dessant/lock-threads)
issue 47, as caused by a version-5 change that adds support for
management of discussions but requires additional permissions
and possibly settings. Given the low notification traffic from
discussions, old discussions may remain valid for a long while, and are
a useful community-interface: Disable management of discussions.
Signed-off-by: Chris Evich <cevich@redhat.com>
Introduce a new GitHub action that will update Podman.io to the newest version of Podman. This action will run on a release being published to GitHub, or by clicking the run workflow button on GitHub. The action will check if the release version is higher than the current version on the website, and open a PR to update the version if a PR does not already exist. The commit will be signed off by the user who triggered the action, so whoever creates the release or presses the run workflow button. The PR will be opened by the podmanbot GitHub account.
Signed-off-by: Ashley Cui <acui@redhat.com>
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>
