Push release as Docker image to atomicregistry/skopeo about skopeo HOT 8 CLOSED

As far as I can tell I'm actually not able to build it my Mac.

If I understand it correctly the Dockerfile assumes a local build of the skopeo binary:
https://github.com/projectatomic/skopeo/blob/master/Dockerfile#L56

from skopeo.

So I've pulled a Fedora machine and build it and pushed the docker image:

$ docker run luebken/skopeo skopeo inspect docker://docker.io/fedora

But it took me quite some time just to fool around with skopeo. So I wouldn't close this and argue that these tools should always be released as a Docker image.

from skopeo.

@luebken I agree - we didn't have any chance to think about that as of yet, I've added enhancement label on this issue so anyone with free cycles can jump here and help.

from skopeo.

Building the Docker image locally takes "for ever"

You just might be the first person to try on a Mac :) Could you be more specific about the process you are using? AFAICS Dockerfile.build is very simple, and skopeo+dependencies is not that much code. (OTOH make check requires a container with compiled OpenShift, and that does take a lot of time and memory to build.)

FWIW the way to do this would be something like make all install; the Dockerfile is not an end-user build mechanism, it is for the integration tests container. (Are we documenting it incorrectly?)

A simple docker run atomicregistry/skopeo would be great.

It would have to be more than that in most scenarios, because skopeo needs to read config files (e.g. Docker registry or OpenShift credentials, signature verification policy). It would probably be possible to make it easy with atomic run (OTOH I’m not sure projectatomic/atomic is available for macOS either).

Having such an image auto-built on merge would be great.

If I understand it correctly the Dockerfile assumes a local build of the skopeo binary:
https://github.com/projectatomic/skopeo/blob/master/Dockerfile#L56

That Dockerfile should only assume that a local compiled binary exists; that can happen either through make binary-local, using a “native” go build, or through make binary, which does the build in a container but mounts the project’s directory into the container, so that the container can create the required compiled binary on the host.

from skopeo.

You just might be the first person to try on a Mac :)

I get the feeling that this is my mission. ;-)

Could you be more specific about the process you are using?

$ make build-container
but that was probably wrong for my purpose

AFAICS Dockerfile.build is very simple, and skopeo+dependencies is not that much code.

+1

I just ran $ make binary that was fast enough. Maybe something to highlight at https://github.com/projectatomic/skopeo#installing ?

It would have to be more than that in most scenarios, because skopeo needs to read config files (e.g. Docker registry or OpenShift credentials, signature verification policy).

Ok. I’m new to skopeo and just ran inspect which worked. Not sure if its enough to mount in the config files for the other use-cases. And if its worth the effort trying to what needs to be mounted it.

from skopeo.

Maybe something to highlight at https://github.com/projectatomic/skopeo#installing ?

Good point, we show make install but that fails in a clean checkout, and we don’t show how to do the build.

It would have to be more than that in most scenarios, because skopeo needs to read config files (e.g. Docker registry or OpenShift credentials, signature verification policy).

Ok. I’m new to skopeo and just ran inspect which worked.

True, read-only access will often work without configuration.

from skopeo.

@luebken @mtrmac @vrothberg Is this still an issue? Can we close this?

from skopeo.

README.md nowadays primarily recommends non-container builds (make binary-local), consistent with

A simple docker run atomicregistry/skopeo would be great.
It would have to be more than that in most scenarios, because skopeo needs to read config files (e.g. Docker registry or OpenShift credentials, signature verification policy).

and also mentions make binary, as suggested in #186 (comment) .

Considering the need to read config files, and that atomic run is has been deemphasized, I don’t think distributing a stand-alone container image is very practical (apart from pure read-only uses like skopeo inspect) right now.

from skopeo.