ROX-15327: Remove Circle CI references and simplify tagging

[gavin-stackrox]

Description

Less is more! And tag determination was overly complicated.

Checklist

• Investigated and inspected CI test results

Testing Performed

• Regular CI - unrelated flake in postgres upgrade
• Release simulation (if possible)

[ghost]

Images are ready for the commit at 4a7a964.

To use with deploy scripts, first export MAIN_IMAGE_TAG=3.74.x-313-g4a7a9640ad.

[msugakov]

Note that CIRCLE_TAG renaming should be mirrored in the downstream. I can help with that.

[msugakov]

After looking at scripts/check-debugger.sh, I remember why there was a difference between BUILD_TAG (former CIRCLE_TAG) and just TAG (that was present in this Makefile before edits) in the context of Makefile.

• BUILD_TAG/CIRCLE_TAG meant a tag provided externally, i.e. from CI when we need to build something like 3.74.1-rc.1.
• TAG held the current value of the tag.
  • If BUILD_TAG/CIRCLE_TAG was provided, TAG simply got its value.
  • Otherwise, TAG held a result of git describe, i.e. some 3.74.x-266-gb6315d348b thingy.

To me this explains the existence of that TAG= trick in make/env.mk (intent, but not a reasoning).

Without such separation, we'll not be able to differentiate tagged (i.e. release, RC, nightly) and untagged builds. It seems to me that scripts/check-debugger.sh is the only place that does that.
Do you know other places?
How broken is the debugger support that we can leave check-debugger.sh in incorrect state?

[msugakov]

It seems to me that scripts/check-debugger.sh is the only place that does that.
Do you know other places?

Here's a deeper example. Our Makefile calls into itself, e.g. in case of main-build-dockerized target

stackrox/Makefile

Lines 404 to 408 in d8f6253

	.PHONY: main-build-dockerized
	main-build-dockerized: main-builder-image
	@echo "+ $@"
	docker run $(DOCKER_USER) -i -e RACE -e CI -e BUILD_TAG -e GOTAGS -e DEBUG_BUILD --rm $(GOPATH_WD_OVERRIDES) $(LOCAL_VOLUME_ARGS) $(BUILD_IMAGE) make main-build-nodeps

The fact that BUILD_TAG environment variable is provided highlights a nice distinction that:

• Every environment variable will be visible as makefile variable with the same name. BUILD_TAG=blah make ... will do $(BUILD_TAG) equal to blah during the Makefile execution.
• However, it does not work the other way. Makefile variable does not become an environment variable with the same name. I.e. when ${BUILD_TAG} is not defined in the environment, main-build-dockerized propagates no BUILD_TAG value into docker run ... -e BUILD_TAG ... context.

This means, main-build-dockerized should still work correctly w.r.t. actual GOTAGS=release (or not) in the resulting binaries, but the part why it works correctly is a bit too subtle.

WDYT, should we keep things the way they are now or should we restore BUILD_TAG-TAG duality in the Makefile for better explicitness?

Looking at it from another angle, the "BUILD_TAG-TAG duality" was to differentiate when we should and shouldn't apply GOTAGS=release during Go binaries build. Maybe that's the place that should be changed to make rules more explicit and straightforward?

[gavin-stackrox]

WDYT, should we keep things the way they are now or should we restore BUILD_TAG-TAG duality in the Makefile for better explicitness?

I think I will put it back the way it was i.e. TAG in the make environment.

[openshift-ci]

@gavin-stackrox: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name	Commit	Details	Required	Rerun command
ci/prow/gke-postgres-upgrade-tests	4a7a964	link	false	/test gke-postgres-upgrade-tests
ci/prow/gke-postgres-qa-e2e-tests	4a7a964	link	false	/test gke-postgres-qa-e2e-tests

Full PR test history. Your PR dashboard.

Details

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. I understand the commands that are listed here.