Followup to #22270: wherever possible/practical, extend command
error checks to include explicit exit status codes and error strings.
This commit handles test/e2e/play_kube_test.go
Signed-off-by: Ed Santiago <santiago@redhat.com>
Followup to #13936 : add an exclusion to localmachine tests
so we can avoid running those on test- or doc-only PRs.
Reason: #22551, the machine-start-timeout flake, is causing
hours of wasted time.
Signed-off-by: Ed Santiago <santiago@redhat.com>
Followup to #22270: wherever possible/practical, extend command
error checks to include explicit exit status codes and error strings.
This commit handles test/e2e/v*_test.go
Signed-off-by: Ed Santiago <santiago@redhat.com>
Extends the `pkg/machine/provider` package to add an API which includes
provider detection based on the host operating system.
Signed-off-by: Jake Correnti <jakecorrenti+github@proton.me>
commit b3014c1c69d5870104aa45f7caae7af041094171 changed
GetRootlessRuntimeDir() to return an empty string for root, so that
its value is not exported as XDG_RUNTIME_DIR, and other programs like
crun can use a better default.
Now GetRootlessPauseProcessPidPath() uses homedir.GetRuntimeDir().
The homedir.GetRuntimeDir() function returns a value also when running
as root so it can be used inside a nested Podman.
Closes: https://github.com/containers/podman/issues/22327
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
Systemd dislikes it when we rapidly create and remove a transient
unit. Solution: If we change the name every time, it's different
enough that systemd is satisfied and we stop having errors trying
to restart the healthcheck.
Generate a random 32-bit integer, and add it (formatted as hex)
to the end of the unit name to do this. As a result, we now have
to store the unit name in the database, but it does make
backwards compat easy - if the unit name in the DB is empty, we
revert to the old behavior because the timer was created by old
Podman.
Should resolve RHEL-26105
Signed-off-by: Matt Heon <mheon@redhat.com>
Some programs have their configuration files relative to the user's
home. It would be convenient being able to mount these into the container, but
that requires expansion of `~` or `$HOME` in a label. This commit adds support
for that for the `runlabel` command.
Signed-off-by: Dan Čermák <dcermak@suse.com>
Followup to #22270: wherever possible/practical, extend command
error checks to include explicit exit status codes and error strings.
This commit handles a subset of test/e2e/pod_xxxx_test.go
(I stopped before this grew too huge for review)
Signed-off-by: Ed Santiago <santiago@redhat.com>
Followup to #22270: wherever possible/practical, extend command
error checks to include explicit exit status codes and error strings.
Signed-off-by: Ed Santiago <santiago@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>
