Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Add unpack ability #75
The way it works is by downloading the file the destination dir when the flag is set, and then if it's an archive it extracts it. If the archive is a .tar.gz it will unpack the tar after gunzipping it. The original archive is not saved.
This should mean that when the
This should also mean that this resource can be used as an
I think this configuration makes more sense in
params, so I opened concourse/concourse#1369 to support that. Would you mind amending this and then once we do the other issue it can be used for
I'm also not a huge fan of recursing as there may be cases where you've got a
.zip in a
.tar.gz because...reasons. Automation can get weird. I'd prefer it to special case
Jul 14, 2017
1 check passed
Ok so I didn't see the reliance on
I'm really uncomfortable with this PR and would prefer if this feature were to be re-implemented, that it only use the standard library of Go, which has zip/tar/gzip support.
While the standard library does support all of those things, it is quite difficult to reproduce the same characteristics you get by default when using the binaries which exist on the rootfs. Un-tarring in particular is quite cumbersome.
The docker-image-resource relies on many binaries being present on the image, see common.sh:
I don't think it's unreasonable to rely on binaries that exist on the rootfs.
Yeah shelling out especially for things like extracting is fine imo. It's a whole lot faster than a native Go implementation and a lot harder to mess up. Fly also shells out to `tar` when it can. My only qualm would be requiring those for the unit tests for local development, but they're not exactly hard to install. You could also have a look at using something like https://github.com/concourse/go-archive which will attempt to shell out and fall back on native go if the binary is not present. Though we should also make sure the rootfs has those binaries for best performance. Also it doesn't have a tarfs package but that would be easy to add.…
On Fri, Jul 21, 2017, 7:32 AM krishicks ***@***.***> wrote: While the standard library does support all of those things, it is quite difficult to reproduce the same characteristics you get by default when using the binaries which exist on the rootfs. Un-tarring in particular is quite cumbersome. The docker-image-resource relies on many binaries being present on the image, see common.sh <https://github.com/concourse/docker-image-resource/blob/master/assets/common.sh> : - mkdir - mountpoint - mount - sed - umount - ln - rm - grep - dockerd - kill - wait I don't think it's unreasonable to rely on binaries that exist on the rootfs. — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <#75 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAAHWL0FB2wlhBpZ44rSLugo2wqzeyURks5sP9TcgaJpZM4OJ79V> .