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>
As we want to get rid of the special titles convert the existing skips
to the only_if condition, this makes it more readable as we do not need
to negate so much.
Then add similar conditions for all test tasks, this removes the need to
a special title such as CI:DOCS as the logic is smart enough to only
docs changes when no source code was changed.
Update the documentation for the new logic and no longer point
contributors to the CI:DOCS title as it is gone now.
There is a bunch of duplication in the rules as yaml doesn't allow us to
share only parts of a string. To prevent unwanted drift a test case in
contrib/cirrus/cirrus_yaml_test.py is added to ensure all conditions
follow the same base ruleset.
Signed-off-by: Paul Holzinger <pholzing@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>
Commit ca66a90b87 was merged without fixing the config. Please read
changelogs before merging renovate PRs, especially when it is a major
version bump.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
The podman in `ubuntu-latest` environment apparently is too old to
support `--userns=keep-id:uid=1000,gid=1000`. Employ workaround in GHA
workflow and in `prebuild.sh` check.
Signed-off-by: Chris Evich <cevich@redhat.com>
As an effort to catch potential secrets and/or credential leaks, add a
github-actions workflow which is untouchable in a PR context.
To additionally guard against accidents, also check recent branch
history. This is especially important on newly created
release-branches, which may begin with content from who-knows-where.
Finally, since the new workflow bypasses PR-level changes to the scanner
config and base-line. Add a Cirrus-CI invocation of the scanning tool
to help catch tool-breaking changes from being merged.
Signed-off-by: Chris Evich <cevich@redhat.com>
Lokesh Mandvekar