Add Target to Extract Binary Artifacts from RPMs #279
Conversation
adamperlin
force-pushed
the
adamperlin/extract-binaries-target
branch
from
40a8141 to
4546004
Compare
|
Haven't determined the source of the CI failures yet, it appears to be some kind of timeout |
cpuguy83
force-pushed
the
adamperlin/extract-binaries-target
branch
from
a4d095e to
d065534
Compare
|
Rebased to include #264 |
The test is using a mariner2 container to test the output of the windowscross/zip target. The platform was incorrectly set to use windows/amd64 for the mariner2 container causing the build to fail. Signed-off-by: Brian Goff <cpuguy83@gmail.com>
Known issues: does not support binary artifact subpaths, this needs to be fixed
cpuguy83
force-pushed
the
adamperlin/extract-binaries-target
branch
from
d065534 to
c47bfa5
Compare
|
Rebased this on top of #280 and tests are passing now. |
Thank you!! |
Remove zip step from bin extract and output raw binaries in llb.State Move bin extract tests under testLinuxDistro Add more descriptive test error messages
Separate handlers for artifacts/binaries and zip into different files and regroup common windows functionality under windows/common.go
…ed bin_extract test file
adamperlin
force-pushed
the
adamperlin/extract-binaries-target
branch
from
e7df5ca to
017835e
Compare
frontend/azlinux/handle_bin.go
Outdated
| #!/bin/bash | ||
| set -e | ||
| declare -a RPMS=() | ||
| export RPM_BINDIR=$(rpm --eval '%{_bindir}') |
There was a problem hiding this comment.
Also, I think (as you mentioned in your commit message) this will not be able to extract executables that aren't in the standard bindir. For example, /usr/libexec (or a subpath of it) will have executable files, and some of the moby packages install files there.
It might be too much of a blunt instrument, but instead of trying to pinpoint the executable files in the rpm, you could just extract everything. Then you can find ./extracted -type f -executable to find the executable files. The downside is you might pick up a script or something that you don't want, but IMO there's no meaningful way to determine ahead of time which "binaries" are desirable vs not.
There was a problem hiding this comment.
I specifically want this to map to the artifact type in the artifact config.
There was a problem hiding this comment.
So just to confirm, are we ok with having this just extract from %{_bindir} (and any subpaths) or do we want to look in any additional locations?
There was a problem hiding this comment.
So just to confirm, are we ok with having this just extract from
%{_bindir}
Yes, unless I've misunderstood.
There was a problem hiding this comment.
Not ignoring this just need some time to think about the edge cases.
|
Thanks for the review and sign off @pmengelbert! After a bit of offline discussion today, I think we've decided to put this PR on hold for now as it may not actually be needed to serve the use case |
|
We discussed this and are thinking this should be handled outside of dalec. |
|
Closing this due to above discussion. |
What this PR does / why we need it:
There is a desire from some Dalec users to extract the binary artifacts produced as part of Dalec's rpm builds as standalone files. This PR adds a target which produces a single zip file containing the binary artifacts specified in a Dalec spec. Only the binaries are included with no dependencies whatsoever, so it is the user's responsibility to ensure that any standalone binaries extracted with this target are fully statically linked.
Which issue(s) this PR fixes (optional, using
fixes #<issue number>(, fixes #<issue_number>, ...)format, will close the issue(s) when the PR gets merged):Fixes #
Special notes for your reviewer: