-
Notifications
You must be signed in to change notification settings - Fork 603
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
Use OCI and OpenShift labels as part of Docker image metadata #9940
Comments
Proposal is to add both the OCI labels and the OpenShift labels to our Dockerfile, ignoring the development stage for now. I think we can remove that stage anyway once our own development cluster is on GKE 1.22+ where we can use ephemeral containers, which will simplify our Dockerfile a bit. Testing will be done via a pseudo-golden file (i.e. a golden file generated during the build of the expected values), and then comparing against the output of
|
10007: Add OCI & OpenShift labels to Docker image r=npepinpe a=npepinpe ## Description This PR adds labels to the Docker image following the OCI and OpenShift specs. This includes modifications to the build process to inject the few values which are dynamic, namely: - the created at ISO 8601 timestamp - the commit SHA (or revision) of the artifact - the semantic version of the artifact You can find the specs here: - https://github.com/opencontainers/image-spec/blob/main/annotations.md - https://docs.openshift.com/container-platform/4.10/openshift_images/create-images.html#images-create-metadata_create-images On top of adding labels, this modifies the `Dockerfile` a bit and pins the production image to specific sha of the base image, ensuring reproducible builds. In the future we should update this sha when need be, and update the golden file (`docker/test/docker-labels.golden.json`). This also adds `hadolint` to lint our Dockerfile and applies some of the recommendations to it. A new code quality job is added, `Docker checks`, which runs hadolint and verifies that the labels are as expected. The verification is done via a bash script which grabs the labels from a `docker inspect`, and compares it with an interpolated golden file (since we have a few dynamic values). The comparison is done using `diff`, so the output should be familiar to most. ## Related issues related to #9940 blocks #10013 10012: refactor: let `dist` build the actor scheduler for gateway r=oleschoenburg a=oleschoenburg ## Description This moves the responsibility of creating an actor scheduler for the gateway to the `dist` module. As an added benefit, this allows us to remove some redundant constructors, simplify BrokerClient to never start the actor scheduler and a deprecated method from `BrokerStartupContext`. ## Related issues <!-- Which issues are closed by this PR or are related --> relates to #9996 Co-authored-by: Nicolas Pepin-Perreault <nicolas.pepin-perreault@camunda.com> Co-authored-by: Ole Schönburg <ole.schoenburg@gmail.com>
Is your feature request related to a problem? Please describe.
As an OpenShift operator, I want to have more information about the applications deployed to my project, as well as tighter integration with the built-in console, in a format I understand, as I may not always know about the specific applications being deployed even as I must maintain them operationally.
Describe the solution you'd like
Image labels are a great and cheap way to convey this information, e.g. minimum amount of cores, memory, is the application scalable, what type of software is it, support/contact info, etc. See the context for more info about this.
Describe alternatives you've considered
We can document our images and their capabilities, as we should (and do). The labels however improve the discovery process for these things.
Additional context
The text was updated successfully, but these errors were encountered: