-
Notifications
You must be signed in to change notification settings - Fork 3.8k
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,release: provide way to inject build tag override, use in MAPB #101943
Conversation
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.
A couple questions:
- Can we also check that Publish Bleeding Edge has a good value for
Build Tag
and, if not, update those builds too?
@@ -52,14 +52,14 @@ git tag "${build_name}" | |||
tc_end_block "Tag the release" | |||
|
|||
tc_start_block "Compile and publish artifacts" | |||
BAZEL_SUPPORT_EXTRA_DOCKER_ARGS="-e TC_BUILDTYPE_ID -e TC_BUILD_BRANCH=$build_name -e gcs_credentials -e gcs_bucket=$gcs_bucket" run_bazel << 'EOF' | |||
BAZEL_SUPPORT_EXTRA_DOCKER_ARGS="-e TC_BUILDTYPE_ID -e TC_BUILD_BRANCH=$build_name -e build_name=$build_name -e gcs_credentials -e gcs_bucket=$gcs_bucket" run_bazel << '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.
I'm curious. Why make build_name
lowercase here?
Also, why not just use TC_BUILD_BRANCH
given they both have the same value?
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 curious. Why make build_name lowercase here?
I didn't "make it lowercase" -- the variable already exists and has a lowercase name. 🤷 Just keeping it the same way it is.
Also, why not just use TC_BUILD_BRANCH given they both have the same value?
Out of an abundance of caution I am not doing this. I am not sure if the value of TC_BUILD_BRANCH
from the host or the container would be used because bash scripts are confusing. (The values differ between the host and container for some reason.) In this case the values of build_name
are the same on host and container so no matter which way place the string interpolation happens, it should be fine.
var doProvisional bool | ||
var isRelease bool | ||
var doBless bool | ||
flag.BoolVar(&isRelease, "release", false, "build in release mode instead of bleeding-edge mode") | ||
flag.StringVar(&gcsBucket, "gcs-bucket", "", "GCS bucket") | ||
flag.StringVar(&outputDirectory, "output-directory", "", | ||
"Save local copies of uploaded release archives in this directory") | ||
flag.StringVar(&tagOverride, "build-tag-override", "", "override the version from version.txt") |
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.
Why drop the build
in tagOverride
? Asking because the word tag
by itself is overloaded and explicitly saying build tag
makes it clearer where the value will end up going.
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.
Fixed.
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 logic looks sane to me. There are some go fmt suggestions and James' comments that need to be addressed before you can merge.
Reviewed 7 of 7 files at r1, all commit messages.
Reviewable status:complete! 0 of 0 LGTMs obtained (waiting on @celiala and @rickystewart)
Already done. These binaries are |
e54988c
to
ecbb86b
Compare
bors r=rail |
bors r- |
Canceled. |
When we build nightly builds, we build them in "release" configuration. Because we do this, the build tag reported by these binaries from `cockroach version` has been identical to that of an actual release binary, which is very confusing. Here we update the script to build these nightlies (`make-and-publish-build-artifacts.sh`) to inject an appropriate, identifiable build tag. It is probably wrong that we are building these nightlies as if they were "releases". We'll follow up with work to fix this and refine the build tags further. Closes cockroachdb#100532. Epic: None Release note (build change): Update reported `Build Tag` for nightly (non-release) builds
ecbb86b
to
cbad692
Compare
bors r=rail |
Build succeeded: |
Encountered an error creating backports. Some common things that can go wrong:
You might need to create your backport manually using the backport tool. error creating merge commit from cbad692 to blathers/backport-release-23.1-101943: POST https://api.github.com/repos/cockroachdb/cockroach/merges: 409 Merge conflict [] you may need to manually resolve merge conflicts with the backport tool. Backport to branch 23.1.x failed. See errors above. error creating merge commit from cbad692 to blathers/backport-release-23.1.0-101943: POST https://api.github.com/repos/cockroachdb/cockroach/merges: 409 Merge conflict [] you may need to manually resolve merge conflicts with the backport tool. Backport to branch 23.1.0 failed. See errors above. 🦉 Hoot! I am a Blathers, a bot for CockroachDB. My owner is dev-inf. |
When we build nightly builds, we build them in "release" configuration. Because we do this, the build tag reported by these binaries from
cockroach version
has been identical to that of an actual release binary, which is very confusing. Here we update the script to build these nightlies (make-and-publish-build-artifacts.sh
) to inject an appropriate, identifiable build tag.It is probably wrong that we are building these nightlies as if they were "releases". We'll follow up with work to fix this and refine the build tags further.
Closes #100532.
Epic: None
Release note (build change): Update reported
Build Tag
for nightly (non-release) builds