Allow override of build git env in docker/base builds

[timvaillancourt]

Description

This PR allows BUILD_GIT_BRANCH and BUILD_GIT_REV to be passed-into docker builds using Dockerfiles from docker/base. Currently it is possible to override CGO_ENABLED and BUILD_NUMBER, but not these git-related vars

Specifically, this is useful when the BUILD_GIT_BRANCH default is not useful (HEAD) and an override from your CI is needed

$ curl -s localhost:15000/debug/vars|jq .BuildGitBranch
"HEAD"

If possible, please backport to v14+ 🙏

Related Issue(s)

Resolves #11967

Checklist

• "Backport to:" labels have been added if this change should be back-ported
• Tests were added or are not required
• Documentation was added or is not required

Deployment Notes

[vitess-bot]

Review Checklist

Hello reviewers! 👋 Please follow this checklist when reviewing this Pull Request.

General

• Ensure that the Pull Request has a descriptive title.
• If this is a change that users need to know about, please apply the release notes (needs details) label so that merging is blocked unless the summary release notes document is included.

If a new flag is being introduced:

• Is it really necessary to add this flag?
• Flag names should be clear and intuitive (as far as possible)
• Help text should be descriptive.
• Flag names should use dashes (-) as word separators rather than underscores (_).

If a workflow is added or modified:

• Each item in Jobs should be named in order to mark it as required.
• If the workflow should be required, the maintainer team should be notified.

Bug fixes

• There should be at least one unit or end-to-end test.
• The Pull Request description should include a link to an issue that describes the bug.

Non-trivial changes

• There should be some code comments as to why things are implemented the way they are.

New/Existing features

• Should be documented, either by modifying the existing documentation or creating new documentation.
• New features should have a link to a feature request issue or an RFC that documents the use cases, corner cases and test cases.

Backward compatibility

• Protobuf changes should be wire-compatible.
• Changes to _vt tables and RPCs need to be backward compatible.
• vtctl command output order should be stable and awk-able.
• RPC changes should be compatible with vitess-operator
• If a flag is removed, then it should also be removed from VTop, if used there.

[deepthi]

@frouioui can you take a look? Also seems like we aren't keeping the bootstrap_version up to date in the vitess/base Dockerfiles. Not sure how those are working right now with such an old bootstrap_version.
Separately, we should probably add you and @GuptaManan100 as code owners for docker files.

[frouioui]

Separately, we should probably add you and @GuptaManan100 as code owners for docker files.

@deepthi, done in #11981.

[frouioui]

This change is looking good to me. I am assuming you are doing manual build of vitess/bootstrap and vitess/base on your own and require the git revision to not be HEAD.

[frouioui]

Also seems like we aren't keeping the bootstrap_version up to date in the vitess/base Dockerfiles. Not sure how those are working right now with such an old bootstrap_version.

@deepthi - The bootstrap version used by vitess/base is in sync with the one used to build vitess/bootstrap. The branch was just not up-to-date with main. I merged main onto that branch.

[timvaillancourt]

I am assuming you are doing manual build of vitess/bootstrap and vitess/base on your own and require the git revision to not be HEAD.

@frouioui yes, that is correct 👍

I haven't figured out why git returns HEAD but overriding with $GIT_BRANCH from our Jenkins build env fixes it. Some googling suggests it's due to a detached-head state in git, perhaps caused by how the Jenkins Git plugin checks out a branch 🤷‍♂️

[mattlord]

Thanks! ❤️

[vitess-bot]

I was unable to backport this Pull Request to the following branches: release-14.0, release-15.0.