Skip to content
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

Merged
merged 1 commit into from
Apr 20, 2023

Conversation

rickystewart
Copy link
Collaborator

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

@rickystewart rickystewart requested review from rail and celiala April 20, 2023 19:11
@rickystewart rickystewart requested a review from a team as a code owner April 20, 2023 19:11
@cockroach-teamcity
Copy link
Member

This change is Reviewable

Copy link
Collaborator

@jlinder jlinder left a 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'
Copy link
Collaborator

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?

Copy link
Collaborator Author

@rickystewart rickystewart Apr 20, 2023

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")
Copy link
Collaborator

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.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed.

Copy link
Member

@rail rail left a 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: :shipit: complete! 0 of 0 LGTMs obtained (waiting on @celiala and @rickystewart)

@rickystewart
Copy link
Collaborator Author

Can we also check that Publish Bleeding Edge has a good value for Build Tag and, if not, update those builds too?

Already done. These binaries are -dev- binaries that have sensible Build Tags already.

@rickystewart rickystewart force-pushed the nightlytag branch 2 times, most recently from e54988c to ecbb86b Compare April 20, 2023 21:26
@rickystewart rickystewart requested a review from jlinder April 20, 2023 21:27
@rickystewart
Copy link
Collaborator Author

bors r=rail

@rickystewart
Copy link
Collaborator Author

bors r-

@craig
Copy link
Contributor

craig bot commented Apr 20, 2023

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
@rickystewart
Copy link
Collaborator Author

bors r=rail

@rickystewart rickystewart added backport-23.1.x Flags PRs that need to be backported to 23.1 backport-23.1.0 labels Apr 20, 2023
@craig
Copy link
Contributor

craig bot commented Apr 20, 2023

Build succeeded:

@craig craig bot merged commit 5ab6451 into cockroachdb:master Apr 20, 2023
@blathers-crl
Copy link

blathers-crl bot commented Apr 20, 2023

Encountered an error creating backports. Some common things that can go wrong:

  1. The backport branch might have already existed.
  2. There was a merge conflict.
  3. The backport branch contained merge commits.

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backport-23.1.x Flags PRs that need to be backported to 23.1
Projects
None yet
Development

Successfully merging this pull request may close these issues.

build: nightlies off master and release-23.1 report incorrect version information
4 participants