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

Add release binaries from git main on push #402

Merged
merged 1 commit into from
Dec 18, 2024

Conversation

cgwalters
Copy link
Contributor

Targeting a few distributions, produce a tarball with binaries.

This is intended to be used in other downstream CI scenarios.

Targeting a few distributions, produce a tarball with
binaries.

This is intended to be used in other downstream CI
scenarios.

Signed-off-by: Colin Walters <[email protected]>
@cgwalters cgwalters enabled auto-merge December 18, 2024 14:59
Copy link
Collaborator

@allisonkarlitskaya allisonkarlitskaya left a comment

Choose a reason for hiding this comment

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

I think this is fine to go in. In my opinion the greatest benefit here is that we get exposure to building on different distributions. Maybe you'd like to run the tests as well?

I'm not sure about how the artifacts themselves might end up being used. It might be more interesting if we did those as part of our release process and attached them to the release where it would be easier to download them.


on: push

permissions:
Copy link
Collaborator

Choose a reason for hiding this comment

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

I didn't know that this could appear at the toplevel! Interesting.

Copy link
Collaborator

Choose a reason for hiding this comment

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

I've usually used permissions: {} for this in the past, but I've also been setting it per-job, so I don't know if it's the same...

@@ -33,9 +48,11 @@ done

# Install packages:
if [ -n "${PACKAGES_REQUIRED}" ]; then
apt -y update
Copy link
Collaborator

Choose a reason for hiding this comment

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

Probably makes sense to do this once, regardless. We know that one set or the other will be non-empty (if not both).

- name: Upload binary
uses: actions/upload-artifact@v4
with:
name: composefs-${{ matrix.basename }}.tar
Copy link
Collaborator

Choose a reason for hiding this comment

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

Is it too difficult to derive this from /usr/lib/os-release of the running container?

--pax-option=exthdr.name=%d/PaxHeaders/%f,delete=atime,delete=ctime
-czf composefs.tar.gz .
- name: Upload binary
uses: actions/upload-artifact@v4
Copy link
Collaborator

Choose a reason for hiding this comment

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

From my memory, artifacts have a fairly limited usefulness in terms of lifetime and not being accessible unless you have an API token or are logged in.

What usecase are you imagining for these? Plucked from a workflow running in a different repository? How would it find them?

@cgwalters cgwalters merged commit 1003b4f into containers:main Dec 18, 2024
13 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants