-
Notifications
You must be signed in to change notification settings - Fork 2.7k
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
image pushing: configure jobs for all Kubernetes-CSI repos #17741
image pushing: configure jobs for all Kubernetes-CSI repos #17741
Conversation
@msau42: do we want to set up jobs before or after updating all repos? Right now, most of the jobs will still fail. |
/hold |
fa84bf0
to
c0935b7
Compare
This is part of rolling out multi-architecture image building for GCR, see kubernetes-csi/csi-release-tools#86
c0935b7
to
2e547f8
Compare
@msau42: there's no dedicated testgrid for csi-test. Should we use this instead? |
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'm fine creating a new testgrid tab for csi-test, or putting all these jobs into a "image_build" tab.
|
||
output="$(dirname $0)/k8s-staging-csi.yaml" | ||
repos=" | ||
csi-driver-host-path |
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 also have csi-driver-nfs, csi-driver-smb, csi-driver-iscsi, external-health-monitor, csi-proxy
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.
Will add those.
testgrid-dashboards: sig-storage-csi-$repo | ||
decorate: true | ||
branches: | ||
# For publishing canary images. Publishing canary images for release branches can |
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.
Does it hurt to enable it on branches that don't have the build files? It will cause the job to fail, there is not much activity happening in release branches.
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.
Besides failed jobs there shouldn't be any negative effect. If you aren't concerned about that, then I can enable also release-.*
branches.
# This is a regex for semver, from https://semver.org/#is-there-a-suggested-regular-expression-regex-to-check-a-semver-string. | ||
# This is okay for upcoming releases, but old releases will not have the necessary cloud build | ||
# files and thus the job will fail. | ||
- ^v(0|[1-9]\d*)\.(0|[1-9]\d*)\.(0|[1-9]\d*)(?:-((?:0|[1-9]\d*|\d*[a-zA-Z-][0-9a-zA-Z-]*)(?:\.(?:0|[1-9]\d*|\d*[a-zA-Z-][0-9a-zA-Z-]*))*))?(?:\+([0-9a-zA-Z-]+(?:\.[0-9a-zA-Z-]+)*))?$ |
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.
Do we need the branches to be specific, or can we enable it on everything?
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 can enable it for all tags. Doing it for all branches makes less sense, because an arbitrary branch name (say, "my-experimental-feature-branch") will then be used as-is in the image tag, which means the image will be built once and then all future branch updates will trigger this error during image pushing:
https://github.com/kubernetes-csi/node-driver-registrar/blob/da1e2a455271eb7c693dbd9835f6419c82e2ee02/release-tools/build.make#L154-L160
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.
So consider this limitation for branches, we somehow need to distinguish here between "real" branches and tags. I kept the semver check because it seemed reasonable enforce that tags on images have that format.
I don't use test grid much (read: not at all) and thus I don't have an opinion on what is better for its users. A separate "image_build" looks okay to me and is easier to handle, so I am going with that. |
…oard As discussed in kubernetes#17741 it's fine to enable jobs that will not succeed. A separate dashboard gets added because it's easier than trying to determine per repo where the job is meant to be shown and because it might be useful to check all of those jobs at one glance.
…oard As discussed in kubernetes#17741 it's fine to enable jobs that will not succeed. A separate dashboard gets added because it's easier than trying to determine per repo where the job is meant to be shown and because it might be useful to check all of those jobs at one glance.
ed4c9a0
to
6af5a71
Compare
/lgtm |
/assign @bartsmykla @spiffxp |
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.
The only thing I think would be really nice to address are
#!/usr/bin/env bash
and usage of array instead of multiline string and others you can decide.
/lgtm
/hold unhold if you'll decide to now address my suggestions
# See the License for the specific language governing permissions and | ||
# limitations under the License. | ||
|
||
output="$(dirname $0)/k8s-staging-csi.yaml" |
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 would suggest using upper case as and marking this as readonly
(ref. https://google.github.io/styleguide/shellguide.html#constants-and-environment-variable-names)
output="$(dirname $0)/k8s-staging-csi.yaml" | |
readonly OUTPUT="$(dirname "$0")/k8s-staging-csi.yaml" |
repos=" | ||
csi-driver-host-path | ||
csi-driver-iscsi | ||
csi-driver-nfs | ||
csi-driver-smb | ||
csi-proxy | ||
csi-test | ||
external-attacher | ||
external-health-monitor | ||
external-provisioner | ||
external-resizer | ||
external-snapshotter | ||
livenessprobe | ||
node-driver-registrar | ||
" |
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.
Same commetn about readonly
and upper case + I would suggest using array
's instead of strings (ref. https://google.github.io/styleguide/shellguide.html#arrays):
repos=" | |
csi-driver-host-path | |
csi-driver-iscsi | |
csi-driver-nfs | |
csi-driver-smb | |
csi-proxy | |
csi-test | |
external-attacher | |
external-health-monitor | |
external-provisioner | |
external-resizer | |
external-snapshotter | |
livenessprobe | |
node-driver-registrar | |
" | |
readonly REPOS=( | |
csi-driver-host-path | |
csi-driver-iscsi | |
csi-driver-nfs | |
csi-driver-smb | |
csi-proxy | |
csi-test | |
external-attacher | |
external-health-monitor | |
external-provisioner | |
external-resizer | |
external-snapshotter | |
livenessprobe | |
node-driver-registrar | |
) |
postsubmits: | ||
EOF | ||
|
||
for repo in $repos; do |
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.
REPOS
is now an array (per last suggestion)
for repo in $repos; do | |
for repo in "${REPOS[@]}"; do |
node-driver-registrar | ||
" | ||
|
||
cat >"$output" <<EOF |
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.
For consistency purposes I would suggest to enclose the variables in braces (ref. https://google.github.io/styleguide/shellguide.html#variable-expansion):
cat >"$output" <<EOF | |
cat > "${OUTPUT}" <<EOF |
EOF | ||
|
||
for repo in $repos; do | ||
cat >>"$output" <<EOF |
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.
For consistency purposes I would suggest to enclose the variables in braces (ref. https://google.github.io/styleguide/shellguide.html#variable-expansion):
cat >>"$output" <<EOF | |
cat >> "${OUTPUT}" <<EOF |
kubernetes-csi/$repo: | ||
- name: post-$repo-push-images |
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.
For consistency purposes I would suggest to enclose the variables in braces (ref. https://google.github.io/styleguide/shellguide.html#variable-expansion):
kubernetes-csi/$repo: | |
- name: post-$repo-push-images | |
kubernetes-csi/${repo}: | |
- name: post-${repo}-push-images |
#! /bin/bash -e | ||
# Copyright 2020 The Kubernetes Authors. | ||
# | ||
# Licensed under the Apache License, Version 2.0 (the "License"); | ||
# you may not use this file except in compliance with the License. | ||
# You may obtain a copy of the License at | ||
# | ||
# http://www.apache.org/licenses/LICENSE-2.0 | ||
# | ||
# Unless required by applicable law or agreed to in writing, software | ||
# distributed under the License is distributed on an "AS IS" BASIS, | ||
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. | ||
# See the License for the specific language governing permissions and | ||
# limitations under the License. |
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.
In our infra-related scripts at k/k8s.io
we are trying to be consistent with Google's shell styleguide so some of my comments will be related to this styleguide, but I'm not gonna block the PR because of this and leave you the decission if you would like to consider the suggestions.
As setting flags directly in shebangs can be broken when calling te script like:
bash script_name.sh
I would suggest
#! /bin/bash -e | |
# Copyright 2020 The Kubernetes Authors. | |
# | |
# Licensed under the Apache License, Version 2.0 (the "License"); | |
# you may not use this file except in compliance with the License. | |
# You may obtain a copy of the License at | |
# | |
# http://www.apache.org/licenses/LICENSE-2.0 | |
# | |
# Unless required by applicable law or agreed to in writing, software | |
# distributed under the License is distributed on an "AS IS" BASIS, | |
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. | |
# See the License for the specific language governing permissions and | |
# limitations under the License. | |
#!/usr/bin/env bash | |
# Copyright 2020 The Kubernetes Authors. | |
# | |
# Licensed under the Apache License, Version 2.0 (the "License"); | |
# you may not use this file except in compliance with the License. | |
# You may obtain a copy of the License at | |
# | |
# http://www.apache.org/licenses/LICENSE-2.0 | |
# | |
# Unless required by applicable law or agreed to in writing, software | |
# distributed under the License is distributed on an "AS IS" BASIS, | |
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. | |
# See the License for the specific language governing permissions and | |
# limitations under the License. | |
set -o errexit |
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.
In our infra-related scripts at k/k8s.io we are trying to be consistent with Google's shell styleguide so some of my comments will be related to this styleguide, but I'm not gonna block the PR because of this and leave you the decission if you would like to consider the suggestions.
The suggestions make sense, but I'd prefer to get the PR merged as-is first because I want the jobs in place before updating the individual repos.
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.
Sure, I don't have problems with doing it in the following up PR, but unfortunately I don't have approving powers so we'll have to wait for @spiffxp or others to approve it
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.
Script enhancements are in #17808.
/assign @spiffxp |
/hold cancel |
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 agree with @bartsmykla's comments. I'm also not sure how sustainable it is to have job generation scripts littered around the /config/jobs dir. I'll /approve for now to unblock but please address in a followup
/approve |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: msau42, pohly, spiffxp 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 |
/test pull-test-infra-bazel |
This applies the https://google.github.io/styleguide/shellguide.html also to the generator script (review feedback from kubernetes#17741).
Should those rather be under |
@pohly: Updated the
In response to this:
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. |
This applies the https://google.github.io/styleguide/shellguide.html also to the generator script (review feedback from kubernetes#17741).
…oard As discussed in kubernetes#17741 it's fine to enable jobs that will not succeed. A separate dashboard gets added because it's easier than trying to determine per repo where the job is meant to be shown and because it might be useful to check all of those jobs at one glance.
This is part of rolling out multi-architecture image building for GCR,
see kubernetes-csi/csi-release-tools#86