[VDF] anago: Publish container images on K8s Infra (k8s-staging-kubernetes) #1199
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
k8s-ci-robot
added
the
do-not-merge/work-in-progress
|
@justaugustus: Adding label: Reasons for blocking this PR:[Changes to certain release tools can affect our ability to test, build, and release Kubernetes. This PR must be explicitly approved by SIG Release repo admins.] 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. |
k8s-ci-robot
added
do-not-merge/blocked-paths
justaugustus
changed the title
justaugustus
changed the title
k8s-ci-robot
added
release-note
23 tasks
Needs kubernetes/k8s.io#673. |
justaugustus
force-pushed
the
vdf
branch
2 times, most recently
from
287bdc8
to
8df5dc4
Compare
12 tasks
justaugustus
force-pushed
the
vdf
branch
2 times, most recently
from
730edd2
to
66d3eed
Compare
k8s-ci-robot
added
size/L
bartsmykla
reviewed
Mar 30, 2020
lib/releaselib.sh
Outdated
Comment on lines
1047
to
1048
| arches=($(ls "$release_images")) | ||
| for arch in "${arches[@]}"; do |
There was a problem hiding this comment.
you can do:
for arch in ${release_images}/*; doThere was a problem hiding this comment.
I went with:
mapfile -t arches < <(find "${release_images}" -maxdepth 1 -mindepth 1 -type d -exec basename {} \;)
for arch in "${arches[@]}"; dobased on the guidance in shellcheck SC2207: https://github.com/koalaman/shellcheck/wiki/SC2207
Using find and basename takes some of the unexpected * behavior out of the equation.
bartsmykla
reviewed
Mar 30, 2020
bartsmykla
reviewed
Mar 30, 2020
bartsmykla
reviewed
Mar 30, 2020
| # @param version - version tag | ||
| # @param build_output - build output directory | ||
| # @return 1 on failure | ||
| release::docker::validate_remote_manifests () { |
There was a problem hiding this comment.
I know in other places in this file it's not being checked but when you are writing new one you should check if the function receives enough arguments it expects and if not fail.
There was a problem hiding this comment.
Thanks! I've added common::argc_validate to both functions. :)
bartsmykla
reviewed
Mar 30, 2020
lib/releaselib.sh
Outdated
Comment on lines
1164
to
1167
| if ! skopeo inspect "docker://${image}:${version}" --raw >/dev/null 2>&1; then | ||
| logecho "Could not find manifest list for ${image}:${version}" | ||
| return 1 | ||
| else | ||
| manifest=$(skopeo inspect "docker://${image}:${version}" --raw) | ||
| fi |
There was a problem hiding this comment.
Have you tried:
manifest=$(skopeo inspect "docker://${image}:${version}" --raw >/dev/null 2>&1)
if [ $? ]; then
logecho "Could not find manifest list for ${image}:${version}"
return 1
fiThere was a problem hiding this comment.
I opted for a bit of a combination of the two:
if ! manifest=$(skopeo inspect "docker://${image}:${version}" --raw); then
logecho "Could not find manifest list for ${image}:${version}"
return 1
fiSee the guidance on shellcheck SC2181: https://github.com/koalaman/shellcheck/wiki/SC2181
k8s-ci-robot
removed
the
lgtm
justaugustus
force-pushed
the
vdf
branch
2 times, most recently
from
cdda749
to
b59d4af
Compare
Here we add 'release::docker::validate_remote_manifests()', a function which validates the existence of image manifests on a remote registry by doing the following: - Using 'skopeo inspect' to retrieve an image manifest - Looping through the architectures and checking for an architecture-specific digest within the manifest using jq We do some minor cleanup by using 'find' and 'basename' to populate arrays for 'for' loops. Additionally, we validate the correct amount of arguments for 'release::docker::validate_remote_manifests()' and 'release::docker::release()' using 'common::argc_validate'. This function closely resembles 'release::docker::release()' and could probably be consolidated. We make the decision to not do this refactor here to minimize the changes to surrounding functions. Signed-off-by: Stephen Augustus <saugustus@vmware.com>
|
@bartsmykla -- Thanks for the great review! I've implement some of your suggestions. :) |
|
Successfully tested this earlier today...
|
justaugustus
changed the title
k8s-ci-robot
removed
the
do-not-merge/work-in-progress
k8s-ci-robot
added
the
lgtm
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: cpanato, hasheddan, justaugustus, saschagrunert The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
justaugustus
removed
the
do-not-merge/blocked-paths
This was referenced Apr 2, 2020
Closed
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What type of PR is this?
/kind feature
What this PR does / why we need it:
As part of the vanity domain flip, we need to be able to publish container images on K8s Infra.
As a domain restriction organization policy is in place on the Google Infra projects, we cannot
completely move staging to K8s Infra until dl.k8s.io is moved as well (both the redirect AND the GCS bucket contents).
So in the meantime, we will instead run the GCB stage/release jobs within the current
kubernetes-release-testGCP project and grant its GCB service account access to write container images into the newk8s-staging-kubernetesstaging project.(Part of the larger effort to move to the stage/release process to K8s Infra: #911)
Special notes for your reviewer:
Blocked on kubernetes/k8s.io#673.Does this PR introduce a user-facing change?