-
Notifications
You must be signed in to change notification settings - Fork 63
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
[Fix/enhancement] dockerimage labels check and attempted to deduplicate #309
Conversation
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
ee03be3
to
eee5072
Compare
Hey Jan! This changes looks good to me 🙂 I added a small comment on the proposal! |
eee5072
to
650db9b
Compare
Okay, I rebased and updated with the change so that the |
Regarding the Anaconda - there are two
and
Is there anything what we want to do with it? Do we want to update the second section to similar format as is e.g. in: https://github.com/opendatahub-io/notebooks/blob/main/base/ubi9-python-3.9/Dockerfile#L3C1-L11C91
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
initial thought which made me hesitate were that, we would need to do this separately in downstream, however as we pretty much follow the similar methodology.
This would indeed help with both streams.
@jstourac can you rebase and update the PR.
Updating the 2nd part exclusively the jupyter/anaconda-x part , same as other would be prefered. |
Thank you, @harshad16, for your review. I'll try to find some time for this this week 🙂 |
650db9b
to
32e90ab
Compare
base/anaconda-python-3.8/Dockerfile
Outdated
authoritative-source-url="${AUTHORITATIVE_SOURCE_URL}" \ | ||
io.openshift.build.commit.ref="${BUILD_COMMIT_REF}" \ | ||
io.openshift.build.source-location="${AUTHORITATIVE_SOURCE_URL}/tree/${BUILD_COMMIT_REF}/base/anaconda-python-3.8" \ | ||
io.openshift.build.image="${IMAGE_REGISTRY}:base-c9s-python-3.9" TODO ????? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@harshad16 I'm not quite sure what value should be put on this place. I wasn't able to find the image in the https://quay.io/repository/opendatahub/workbench-images - did I miss it somehow? 🤔
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This particular is not built on the ODH,
it is exclusively only built downstream.
we should probably clean a few of these.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see. So, do you prefer me to remove just this io.openshift.build.image
label or all four in this case?
The first three are still valid and could be reused for the downstream part. Although, if there is no image build in upstream, I understand that it doesn't make much sense to have them here either.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah true,
we can remove all of these:
authoritative-source-url
io.openshift.build.commit.ref
io.openshift.build.source-location
io.openshift.build.image
as this more for anyone , who would like to build it, though we wouldn't be building it in upstream.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you, Harshad! Updated 🙂
This change tries to deduplicate some strings in our docker image labels with ability to propagate some common values directly from the Makefile so we don't need to change these values with every release branch or for every newly introduced docker image. There were some minor fixes in the labels introduced too in this commit. --- Relates to: opendatahub-io#292
7d22572
to
1326d63
Compare
The PR looks great, my major concern is this would break the current CI build from openshift CI |
Thank you, Harshad, for pointing this out. I missed that bits. I'll try to check whether I am able to amend our CI so we can merge this eventually. |
PR needs rebase. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
Due to this, we are changing this PR to the draft. |
@jstourac: The following tests failed, say
Full PR test history. Your PR dashboard. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here. |
Relates to: #292
Docker image labels reviewed
Description
This change tries to deduplicate some strings in our docker image labels with ability to propagate some common values directly from the Makefile so we don't need to change these values with every release branch or for every newly introduced docker image.
There were some minor fixes in the labels introduced too in this commit.
Notable points for discussion:
RELEASE
variable for the build-ref at the moment - I understand that this may not be ideal. We may introduce separate value for this in Makefile or we can try to compute the value (either ref hash or branch name) dynamically in Makefile too. But in general - the value of theRELEASE
should match what we've used so far.authoritative-source-url
andbuild commit ref
at least) could be propagated directly from Makefile - in this case I mean by using the--label
parameter. There are two drawbacks I can think of:s2i
infix - we would have to assure we don't change it wrongly.s2i
infixes?How Has This Been Tested?
I did a brief build of one image so far to check the idea behind the changes works. Will do more once the conversation here is finalized:
Result images can be seen in https://quay.io/repository/jstourac/workbench-images?tab=tags&tag=latest
Merge criteria: