-
Notifications
You must be signed in to change notification settings - Fork 38
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
Conversation
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]>
There was a problem hiding this 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: |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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?
Targeting a few distributions, produce a tarball with binaries.
This is intended to be used in other downstream CI scenarios.