Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[CI:ALL] Bump to v5.4.0-RC3 #25225

Merged
merged 14 commits into from
Feb 5, 2025
Merged

Conversation

mheon
Copy link
Member

@mheon mheon commented Feb 4, 2025

As the title says

Does this PR introduce a user-facing change?

NONE

Allow the user to provide an Ansible playbook file on init which will
then be run on boot.

Signed-off-by: Jake Correnti <[email protected]>
Signed-off-by: Brent Baude <[email protected]>
@openshift-ci openshift-ci bot added release-note-none approved Indicates a PR has been approved by an approver from all required OWNERS files. labels Feb 4, 2025
@mheon mheon changed the title Bump to v5.4.0-RC3 [CI:ALL] Bump to v5.4.0-RC3 Feb 4, 2025
FedeDP and others added 9 commits February 4, 2025 15:13
`argv[0]`, ie: the full buffer allocated by `get_cmd_line_args`,
was going to be freed only if `can_use_shortcut()` was called.
Instead, let `init()` always manage `argv0` lifecycle.

Signed-off-by: Federico Di Pierro <[email protected]>
Closes: containers#25163

Signed-off-by: Giuseppe Scrivano <[email protected]>
pass down the devices specifies in the resources block so that CDI
devices in the compose file are honored.

Tested manually with the following compose file:

services:
  testgpupodman_count:
    image: ubuntu:latest
    command: ["nvidia-smi"]
    profiles: [gpu]
    deploy:
      resources:
        reservations:
          devices:
          - driver: nvidia
            count: 1
            capabilities: [gpu]
  testgpupodman_deviceid:
      image: docker.io/ubuntu:latest
      command: ["nvidia-smi"]
      deploy:
        resources:
          reservations:
            devices:
            - driver: cdi
              device_ids: ['nvidia.com/gpu=all']
              capabilities: [gpu]

Closes: containers#19338

Signed-off-by: Giuseppe Scrivano <[email protected]>
podman artifact add now supports two new command line switches.

--type string that describes the type of artifact
--annotation string slice in the form of key=val

These new options allow users to "tag" information in on their artifacts
for any number of purposes down the line

RUN-2446

Signed-off-by: Brent Baude <[email protected]>
added a --no-trunc flag to artifact ls, which follows what images has
done.  by default now, the ls output will have the shortened 12
character digest.  the --no-trunc will output the full digest.

Signed-off-by: Brent Baude <[email protected]>
like images and containers, it could be handy to have a --noheading
option that removes the headings on the output.

Signed-off-by: Brent Baude <[email protected]>
First use proper ginkgo error handling to ensure errors are actually
reported and fail the test. Mark it as helper function to have better
stack traces.

Then use a atomic write function to prevent issues with partial written
files. I think this is causing CI flakes[1].

Lastly fix the file permissions, do not make it world writable and do
not set the executable bit on the file.

[1] https://api.cirrus-ci.com/v1/artifact/task/5985244932734976/html/int-podman-fedora-41-root-host-sqlite.log.html#t--Podman-network-podman-network-ID-test--1

Signed-off-by: Paul Holzinger <[email protected]>
Allowing for multiple manifest per artifact just makes the code and cli
design harder to work with it. It is not clear how mounting, extracting
or edit on a multi manifest artifact should have worked.

A single manifest should make the code much easier to work with.

Signed-off-by: Paul Holzinger <[email protected]>
BuildOrigin is a field that can be set at build time by packagers. This helps us trace how and where the binary was built and installed from, allowing us to see if the issue is due to a specfic installation or a general podman bug. This field shows up in podman version and in podman info when populated. Note that podman info has a new field, Client, that only appears when running podman info using the remote client.

Automatically set the BuildOrigin field when building the macOS pkginstaller to pkginstaller.

Usage: make podman-remote BUILD_ORIGIN="mypackaging"

Signed-off-by: Ashley Cui <[email protected]>
@github-actions github-actions bot added the kind/api-change Change to remote API; merits scrutiny label Feb 4, 2025
@mheon
Copy link
Member Author

mheon commented Feb 4, 2025

Alright, I think this is ready now. Lot of backports in.

@TomSweeneyRedHat
Copy link
Member

LGTM
Build test is still not happy with life.

RELEASE_NOTES.md Outdated
@@ -23,6 +24,7 @@
### Changes
- Podman now passes container hostnames to Netavark, which will use them for any DHCP requests for the container.
- Partial pulls of `zstd:chunked` images now only happen for images that have a `RootFS.DiffID` entry in the image's OCI config JSON, and require the layer contents to match. This resolves issues with image ID ambiguity when partial pulls were enabled.
- Packagers can now set the `BUILT_FOR` environment variable when building podman from the `Makefile`. This provides information on who built the Podman binary, and is displayed in `podman version` and `podman info`. This will help upstream bug reports, allowing maintainers to trace how and where the binary was built and installed from.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

BUILT_FOR is wrong, look at the diff it is using BUILD_ORIGIN in the Makefile

Also not here of course but we really should set this in our rpm specfile here as well.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can BUILD_ORIGIN be any random string?

I guess we could get this in for v5.4.0 final.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ah ok, just tried it. Build Origin: foo . For rpm, we could set it to something like Build Origin: rhcontainerbot/podman-next and Build Origin: Koji for copr v/s koji rpms.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes something like that, not sure if koji is good name as I don't think many know what koji is.
I was thinking in lines of fedora-offical, centos-offical, rhel-offical or something like it so we know it is from the official repos. Then maybe other official/main distro packages can match that we could have some consistency at least, e.g. debian-offical, arch-offical.
Using rhcontainerbot/podman-next sounds like a good thing for the copr builds there.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Adjusted release notes for the right environment var

Copy link
Member

@lsm5 lsm5 Feb 5, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

WIP at #25235 . We're not using Makefile for building the binaries, so I'm setting LDFLAGS separately in the spec file.

Copy link

Ephemeral COPR build failed. @containers/packit-build please check.

Copy link
Member

@Luap99 Luap99 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

Copy link
Contributor

openshift-ci bot commented Feb 5, 2025

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: Luap99, mheon

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@Luap99
Copy link
Member

Luap99 commented Feb 5, 2025

/lgtm

@openshift-ci openshift-ci bot added the lgtm Indicates that a PR is ready to be merged. label Feb 5, 2025
@openshift-merge-bot openshift-merge-bot bot merged commit 582d718 into containers:v5.4 Feb 5, 2025
86 of 90 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approved Indicates a PR has been approved by an approver from all required OWNERS files. kind/api-change Change to remote API; merits scrutiny lgtm Indicates that a PR is ready to be merged. machine release-note-none
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants