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

Publish container image #38

Closed
JamieMagee opened this issue Jan 4, 2022 · 5 comments · Fixed by #220
Closed

Publish container image #38

JamieMagee opened this issue Jan 4, 2022 · 5 comments · Fixed by #220
Labels
status:requirements Full requirements are not yet known, so implementation should not be started type:ci Build or repository configuration

Comments

@JamieMagee
Copy link
Member

JamieMagee commented Jan 4, 2022

To make Component Detection easier to consume and use, we should start publishing container images.

Two open questions are:

  1. What should we use as a base image?
  2. Where should we publish our image?

1. What should we use as a base image?

For our base image, we can use a one of dotnet's runtime-deps images1 once #37 is merged. These images don't have any dotnet runtime installed, which makes them a lot smaller than the standard runtime images.

These are currently the .NET Core 3.1 tags available:

Tags

3.1
3.1-alpine
3.1-alpine-arm64v8
3.1-alpine3.12
3.1-alpine3.12-arm64v8
3.1-alpine3.13
3.1-alpine3.13-arm64v8
3.1-alpine3.14
3.1-alpine3.14-arm64v8
3.1-bionic
3.1-bionic-arm32v7
3.1-bionic-arm64v8
3.1-bullseye-slim
3.1-bullseye-slim-arm32v7
3.1-bullseye-slim-arm64v8
3.1-buster-slim
3.1-buster-slim-arm32v7
3.1-buster-slim-arm64v8
3.1-cbl-mariner1.0
3.1-focal
3.1-focal-arm32v7
3.1-focal-arm64v8

For simplicity, we may want to use 3.1-bullseye-slim, but 3.1-cbl-mariner1.0 and 3.1-alpine3.14 may also be considered

2. Where should we publish our image?

We should push to the Microsoft Container Registry2, but we might also want to push to the GitHub Container Registry as well.

Footnotes

  1. https://github.com/dotnet/dotnet-docker/tree/main/src/runtime-deps/3.1

  2. https://github.com/microsoft/containerregistry

@JamieMagee JamieMagee added status:ready Ready to start implementation type:ci Build or repository configuration status:requirements Full requirements are not yet known, so implementation should not be started and removed status:ready Ready to start implementation labels Jan 4, 2022
@tevoinea
Copy link
Member

I'm a little unclear on how component detection will be used in this scenario. Is the expectation that:

  • Users will base their container images on the component detection image to make the tool available?
    Example:
FROM component-detection:latest
# do normal build stuff
RUN component-detection scan --SourceDirectory ...
  • Users will mount their intended scan directory when running the component detection container to scan?
    Example:
docker run --rm -v $(pwd):/scan component-detection:latest ...
  • Something else I'm not thinking about?

@JamieMagee
Copy link
Member Author

The scenario I had in mind was your 2nd one: users will mount their scan directory in the container.

@sbs2001
Copy link

sbs2001 commented Aug 22, 2022

@JamieMagee Since the detectors have dependency on various language runtimes IMHO using bullseye-slim would be much simpler as installation of these is easy. On alpine, for eg there's no way to install golang without compiling it AFAIK.

Should I make a PR with an image based on this ? It'll have all the major runtimes installed + tool ofc.

@JamieMagee
Copy link
Member Author

@sbs2001 I'd actually been looking at this last month but didn't open a PR for it. If I get it to PR would you be up for reviewing it? Here's what I have so far

@sbs2001
Copy link

sbs2001 commented Aug 29, 2022

@JamieMagee I've posted a review comment on the PR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status:requirements Full requirements are not yet known, so implementation should not be started type:ci Build or repository configuration
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants