Reconsider our approach to OSS vs. commercial builds

[snicoll]

We've tried to setup our CI so that it is as close as possible between OSS builds and enterprise support builds, using a single spring.build-type switch.

After a lot of iterations, the build itself seems to work (although it could break without us noticing until the next branch enters commercial support). However, CI never did.

Promote release requires "sync to maven central" to complete but it will not with a commercial build:

spring-boot/.github/workflows/release.yml

Lines 82 to 86 in 3754efb

	promote-release:
	name: Promote Release
	needs:
	- build-and-stage-release
	- sync-to-maven-central

Same for the publication of the release notes that depends on a number of steps that must be skipped for commercial builds:

spring-boot/.github/workflows/release.yml

Lines 160 to 168 in 3754efb

	create-github-release:
	name: Create GitHub Release
	needs:
	- build-and-stage-release
	- promote-release
	- publish-gradle-plugin
	- publish-to-sdkman
	- trigger-docs-build
	- update-homebrew-tap

Diffing .github between 3.3.x and 3.4.x can adapt CI pretty easily. Yes, it is a manual step but it also helps with long maintenance and simplify the build greatly.

I think we should revisit our decision. Introducing consistent variables and secrets could help reducing the noise to a bare minimum.

Here is an example where the if/else dance could go away with a consistent variable name:

spring-boot/.github/workflows/release.yml

Line 92 in 3754efb

JF_ENV_SPRING: ${{ vars.COMMERCIAL && secrets.COMMERCIAL_JF_ARTIFACTORY_SPRING || secrets.JF_ARTIFACTORY_SPRING }}

[wilkinsona]

Introducing consistent […] secrets

The secret names are out of our control as they're managed org-wide. Being org-wide also requires them to have different names otherwise there would be a clash. Perhaps we can alias things somehow, but I think we have to consider changing the names of the secrets themselves to be out of scope.