switch releasing based on tag

[radTuti]

Description

This creates a separate semaphore file to use for releasing Operator based off tagging

For PR author

• Tests for change.
• If changing pkg/apis/, run make gen-files
• If changing versions, run make gen-versions

For PR reviewers

A note for code reviewers - all pull requests must have the following:

• Milestone set according to targeted release.
• Appropriate labels:
  • kind/bug if this is a bugfix.
  • kind/enhancement if this is a a new feature.
  • enterprise if this PR applies to Calico Enterprise only.

[tmjd]

It seems like we're changing how we're cleaning the cache to make the building of a tag quicker with the result of slowing down any re-runs of a failed run. I would guess re-runs are going to happen much more often than tag builds. So that seems like a bad trade off.

Also does this mean if someone tagged before the Build ran that this would fail?

Seems like a tag should trigger the main operator Semaphore pipeline which should then have a promotion of the 'release.yaml' pipeline if it is on a tag.

[tmjd]

One minor comment that you can ignore if you don't think it would help.

[radTuti]

/merge-when-ready squash-commits delete-branch

[marvin-tigera]

OK, I will merge the pull request when it's ready, squash the commits when I merge it, and delete the branch after I've merged it.

[marvin-tigera]

I'm sorry but I failed delete the branch after merging the pull request.