Trigger CRT workflows for main branch

[nathancoleman]

Changes proposed in this PR:

• Add main to the list of branches that trigger Common Release Tooling workflows. This will produce the dev_tags images of consul-api-gateway defined here onto hashicorppreview whenever we push commits to main. Matches what Consul is doing here.
• Change CRT notification target to different Slack channel where the additional noise created by merges to main won't interrupt our daily conversations.
• Publish mutable + immutable dev_tags so that we can always test with a specific image even after newer versions have been published. I used the naming patterns from Consul's hashicorppreview repo here.
• Change version.go to reflect our next release, 0.3.0, so that dev tags reflect the in-progress work correctly

How I've tested this PR:

There's not a good way to test this change without having the modified actions file merged into main, but the stakes are very low since we're only modifying our own internal process.

How I expect reviewers to test this PR:

Checklist:

• Tests added
• CHANGELOG entry added

  Run make changelog-entry for guidance in authoring a changelog entry, and
  commit the resulting file, which should have a name matching your PR number.
  Entries should use imperative present tense (e.g. Add support for...)

[sarahalsmiller]

Does it matter that the -dev tag will still be applied to preview builds in our release branches? Otherwise looks fine to me.

[nathancoleman]

I don't think it particularly matters, but it might get kinda gross. I might leave as-is for release branches and fork to publish consul-api-gateway:main-latest, consul-api-gateway:main-<sha> for the main branch. Thoughts?

That way each release branch is publishing it's version, but we aren't publishing from main branch as <most-recent-version>-dev which can be kinda confusing

[mdeggies]

The consul PR was recently updated. Just want clarify the names of tags as the PR currently stands--

PR's merged to release/0.2.x will trigger artifact builds, including docker dev builds. Tags will be called:

• hashicorppreview/consul-api-gateway:0.2.1-dev. There's no prerelease string set on this release branch, but since you added the static -dev prefix to the tag in dev_tags, that will be added a suffix. This tag will be updated every time a new PR is merged.
• hashicorppreview/consul-api-gateway:0.2.1-dev-$GITSHA. This tag will be static and will never be updated since it points to a specific git commit sha.

On merges to main, since the version string is also set to 0.2.1 with no prerelease, hashicorppreview/consul-api-gateway:0.2.1-dev will be updated to the head of main.

[mdeggies]

Whoops, I hit send too quickly. We need to document this better, but dropping the patch version from the release branches is an option. The tags from release branches will then be <major>.<minor>-dev and <major>.<minor>-$gitsha, and main would have the patch version.

[mikemorris]

LGTM with caveat that we may want to tweak the dev tag format slightly. +1 to doing something different with the main branch so we don't end up with a misleading tag name (having 0.2.1-dev represent potential 0.3.0 prerelease work while 0.2-dev accurately represents an upcoming 0.2.2 release feels undesirable), not sure if there's any existing convention around just like a plain dev and dev-$GITSHA tag instead of something verbose/redundant like main-latest?

[mikemorris]

Could we slice off the patch segment so this is just MAJOR.MINOR-dev to reflect the intended change in hashicorp/consul#13308?

[nathancoleman]

I love this idea; however, my focus this PR is just getting the main branch published to unblock other work.

Mind if we circle back with a targeted PR to change how we're tagging for release/* branches?

[mikemorris]

@mdeggies Should we consider keeping VersionPrerelease = "dev" in all release branches (and only changing it for specific prerelease or GA tags) rather than appending this tag in CI config?

[nathancoleman]

I've differentiated the main branch dev_tags so that we don't wind up with misleading tags including version numbers.

• Commits on release/* branches will be tagged as hashicorppreview/consul-api-gateway:<version>-dev where the version will reflect the next patch version
• Commits on main branch will be tagged as both:
  • hashicorppreview/consul-api-gateway:<version>-dev where the version will reflect the next minor version
  • hashicorppreview/consul-api-gateway:<version>-<commit_sha>-dev where the version will reflect the next minor version

The above all require that we change our workflow a little to update version.go to reflect the next version as soon as we cut a release.

• Release branches should always be incremented to the next patch version
• Main branch should always be incremented to the next minor version

[nathancoleman]

Discussed with @mdeggies a bit ago and have a plan for additional changes to fit RelEng's new guidelines. The main part will be a workflow change for our team. More to come, but draft for now

[mdeggies]

This looks great Nathan! 🥇