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
build: drop base image #2771
base: master
Are you sure you want to change the base?
build: drop base image #2771
Conversation
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: dkoshkin 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 |
Started Vanilla block pre-checkin pipeline... Build Number: 2618 |
|
@@ -17,7 +17,7 @@ | |||
ARG GOLANG_IMAGE=golang:1.21 | |||
|
|||
# This build arg allows the specification of a custom base image. | |||
ARG BASE_IMAGE=gcr.io/cloud-provider-vsphere/extra/csi-driver-base:latest | |||
ARG BASE_IMAGE=photon:4.0 |
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.
Is there a possibility of observing "docker image pull rate limit" error from docker.io/library/photon:4.0
?
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.
Good question @chethanv28, the limit is 100 requests per IP per 6 hours. Depending on how the runners are setup the image may be cached between runs.
I can't answer if thats enough or not for sure, but looking at the PRs and commit history I don't think that would be a problem.
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.
We need to make sure our internal pipelines are not affected due to this rate limit.
cc: @sashrith
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.
we are setting this base image variable while building the syncer and driver images which is passed to docker buildx to override the default in the dockerfile
vsphere-csi-driver/hack/release.sh
Line 60 in 3345236
GOLANG_IMAGE=${CUSTOM_REPO_FOR_GOLANG:-}golang:1.21 |
we can do something similar to that here as well
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 can change that @sashrith, but is all of CI using the release.sh
script? If not then we may not want to pass in the ARG since now we would need to remember to change the value in multiple different places.
I also see
vsphere-csi-driver/.gitlab-ci.yml
Lines 40 to 41 in 3345236
- sed -i "s#ARG GOLANG_IMAGE=.*#ARG GOLANG_IMAGE=$CNS_IMAGE_GOLANG#g" images/driver/Dockerfile | |
- sed -i "s#ARG GOLANG_IMAGE=.*#ARG GOLANG_IMAGE=$CNS_IMAGE_GOLANG#g" images/syncer/Dockerfile |
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 think this file is used for pushing the image to gcr repo and @divyenpatel has more context on this.
All of the other jobs use release.sh script.
Ran basic e2e test using the internal infra. |
The Kubernetes project currently lacks enough contributors to adequately respond to all PRs. This bot triages PRs according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale |
What this PR does / why we need it:
Stop building the base image and instead move the simple logic directly into the driver and syncer images.
We want to still keep running
tdnf -y upgrade
to upgrade packages with CVE fixes.Although, when I just checked
tdnf -y upgrade
was a no-op.Which issue this PR fixes (optional, in
fixes #<issue number>(, fixes #<issue_number>, ...)
format, will close that issue when PR gets merged): fixes #2768Testing done:
A PR must be marked "[WIP]", if no test result is provided. A WIP PR won't be reviewed, nor merged.
The requester can determine a sufficient test, e.g. build for a cosmetic change, E2E test in a predeployed setup, etc.
For new features, new tests should be done, in addition to regression tests.
If jtest is used to trigger precheckin tests, paste the result after jtest completes and remove [WIP] in the PR subject.
The review cycle will start, only after "[WIP]" is removed from the PR subject.
Tested by building the images locally with
make images
.Special notes for your reviewer:
Release note: