Add promotion step to drone pipeline for pushing to quay

[logand22]

As a part of #438, this PR adds additional pipelines to .drone.yml file in order to promote internally staged docker images to their public registry with quay.io.

The current promotion workflow occurs on a per tag basis. This means that for every tag created by the make update-tag target, a teleport employee triggers a promotion step for this tag.

This workflow is reflected in the additional promotion steps added in this PR. Therefore, no change to the procedure in which a tag is promoted will occur in order for the images to be promoted to Quay.io.

Testing

The promotion step was confirmed through local manual testing.

[wadells]

Testing

The promotion step was confirmed through local manual testing.

How do you plan to test this after merge? I'd like to make sure we've done end-to-end testing before the next 9.0.x release, when these would go live.

[wadells]

Looks reasonable.

[logand22]

@wadells

My current plan is to walk through an entire release process with a dummy tag and dummy promote. I will only be promoting the publish-images target and plan on cleaning up the tags afterwards.

For example:

tag 0.0.193 -> triggers drone push to ecr -> test the images -> run promotion on those tags -> check and test quay images. 

[wadells]

My current plan is to walk through an entire release process with a dummy tag and dummy promote. I will only be promoting the publish-images target and plan on cleaning up the tags afterwards.

For example:

tag 0.0.193 -> triggers drone push to ecr -> test the images -> run promotion on those tags -> check and test quay images. 

This sounds great! The one addendum I'd add is:

Use a tag like 9.0.2-dev.1 and don't delete the tag afterwards. The artifacts can probably be cleaned up from the prod repo -- staging doesn't need to be cleaned up.

Why? Russell asks folks not to delete any tags (including testing ones) from core product repos. A long time ago, an engineer re-pushed a git tag our customers had all ready pulled, and it spooked a customer. After that incident then we've treated tags as immutable for teleport -- even testing tags. I wish we could enforce that immutability it via github, but it isn't possible currently.

We can play a bit more fast and loose with tags in non-customer-facing or non-product repos.

[logand22]

Use a tag like 9.0.2-dev.1 and don't delete the tag afterwards. The artifacts can probably be cleaned up from the prod repo -- staging doesn't need to be cleaned up.

That sounds good. Just to clarify though, leave the git tag alone but clean up the production images in quay?

[wadells]

Use a tag like 9.0.2-dev.1 and don't delete the tag afterwards. The artifacts can probably be cleaned up from the prod repo -- staging doesn't need to be cleaned up.

That sounds good. Just to clarify though, leave the git tag alone but clean up the production images in quay?

Yeah -- thats probably what I'd do. I don't think leaving test images around is harmful, but nor is it particularly helpful to our customers.

[r0mant]

With a couple of comments.