We can just calculate the cpu percent for the time the container is
running. There is no need to use datapoints.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
When you run podman stats, the first interval always shows the wrong cpu
usage. To calculate cpu percentage we get the cpu time from the cgroup
and compare this against the system time between two stats. Since the
first time we do not have a previous stats an empty struct is used
instead. Thus we do not use the actual running time of the container but
the current unix timestamp (time since Jan 1 1970).
To fix this we make sure that the previous stats time is set to the
container start time, when it is empty.
[NO NEW TESTS NEEDED] No idea how I could create a test which would have
a predictable cpu usage.
See the linked bugzilla for a reproducer.
Fixes https://bugzilla.redhat.com/show_bug.cgi?id=2066145
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
In general continuous-delivery (CD) tends to pair well with CI. More
specifically, there is a need for some reverse-dependency CI testing in
netavark/aardvark-dns. In all cases, the download URL needs to remain
consistent, without elements like `Build%20for%20fedora-35`.
The 'Total Success' task only ever executes when all dependencies are
successful. When a non `[CI:DOCS]` build is successful, gather all
binary/release artifacts in a new task which depends on 'Total Success'.
This will provide a uniform name (`artifacts`) and URL for downstream
users to use. For example:
https://api.cirrus-ci.com/v1/artifact/github/containers/podman/artifacts/binary.zip
or
https://api.cirrus-ci.com/v1/artifact/github/containers/podman/artifacts/binary/FILENAME
Where ***FILENAME*** is one of:
* `podman`
* `podman-remote`
* `rootlessport`
* `podman-release-386.tar.gz`
* `podman-release-amd64.tar.gz`
* `podman-release-arm64.tar.gz`
* `podman-release-arm.tar.gz`
* `podman-release-mips64le.tar.gz`
* `podman-release-mips64.tar.gz`
* `podman-release-mipsle.tar.gz`
* `podman-release-mips.tar.gz`
* `podman-release-ppc64le.tar.gz`
* `podman-release-s390x.tar.gz`
* `podman-remote-release-darwin_amd64.zip`
* `podman-remote-release-darwin_arm64.zip`
* `podman-remote-release-windows_amd64.zip`
* `podman-v4.0.0-dev.msi`
Signed-off-by: Chris Evich <cevich@redhat.com>
ginkgo netavark logs (and, to a lesser extent, cni logs)
are unreadable because the hide-boring-opts code did not
know about --network-backend. Now it does.
Manually filtered an existing netavark log to confirm there
are no other new options we should know about.
Signed-off-by: Ed Santiago <santiago@redhat.com>
podman build fails on remote build when using a relative context directory.
This is because the context dir was not being added to the tar, so when remote
the compat build function would not be able to stat the contextDir.
resolves#13293
Signed-off-by: cdoern <cbdoer23@g.holycross.edu>
Add a CI check to prevent unwanted bloat in binary images,
by building a baseline (pre-PR) binary then comparing file
sizes post-PR.
We piggyback onto the existing 'Build Each Commit' CI check
because it gives us an easy way to run 'make' against the
parent commit.
This is part 1 of 2: adding the script, not the Makefile rule.
We can't add the Makefile rule now because the script it would
invoke does not exist in the parent commit.
Signed-off-by: Ed Santiago <santiago@redhat.com>
Still an unknown number remains but I am running out of patience.
Adding dots is not the best use of my time.
Signed-off-by: Valentin Rothberg <vrothberg@redhat.com>
We need to keep disabling the `nolintlint` linter to continue using
`nolint` directives in the code.
Signed-off-by: Valentin Rothberg <vrothberg@redhat.com>
Disabling tagliatelle would mean disabling it for hundreds of fields
that cannot be changed due to K8s or Docker or backwards compat.
Signed-off-by: Valentin Rothberg <vrothberg@redhat.com>
Make sure we're waiting for the ls container to finish to prevent
potential flakes or future regressions.
Spotted while enabling a linter.
Signed-off-by: Valentin Rothberg <vrothberg@redhat.com>
Containers started with `--no-healthcheck` are configured to contain no
healthcheck and test configured as `NONE`. Podman shows wrong status as
such use cases.
Following commit fixes the faulty behavior of stauts field for
containers started with `--no-healthcheck`
Signed-off-by: Aditya R <arajan@redhat.com>
The calculate the percentage we need floating point numbers. The current
code however casted the result of reclaimable/size to an int first.
Casting to an int in go will just discard the decimal points, thus the
result was either 0 or 1 so if multiplied by 100 it would show up as 0%
or 100%.
To fix this we have to multiply by 100 first before casting the result
to an int. Also add a check for div by zero which results in NaN and use
math.Round() to correctly round a number.
Ref #13516
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
One of the pod tests was leaving a stray image behind,
causing scary red warnings in CI logs. Clean that up.
Also, now that #13541 has merged, use 'rmi --ignore' instead of
ignoring exit status from rmi
Signed-off-by: Ed Santiago <santiago@redhat.com>
* supports Go 1.18
* disable a number of new linters
* fix minor stylecheck issues
[NO NEW TESTS NEEDED]
Signed-off-by: Valentin Rothberg <vrothberg@redhat.com>
Add an `--ignore` flag to `podman image rm` to instruct ignoring image
if a specified image does not exist and to not throw an error. Other
commands (e.g., `podman container rm`) already support this flag.
Such an `--ignore` flag can come in handy in clean-up scripcts such as
the teardown phases in the Podman tests.
Signed-off-by: Valentin Rothberg <vrothberg@redhat.com>
- Updated dependabot to get updates for GitHub actions.
GitHub sends Dependabot alerts when we detect vulnerabilities affecting your repository
as well as when there are new updates to the dependency.
https://docs.github.com/en/code-security/dependabot/dependabot-alerts/about-dependabot-alerts
A vulnerability is a problem in a project's code that could be exploited to damage the confidentiality, integrity, or availability of the project or other projects that use its code. Vulnerabilities vary in type, severity, and method of attack.
When your code depends on a package that has a security vulnerability, this vulnerable dependency can cause a range of problems for your project or the people who use it.
Signed-off-by: naveensrinivasan <172697+naveensrinivasan@users.noreply.github.com>
