Push Access Plugins and Event Handler Docker Images to ECR

[logand22]

This PR is a part of #438

This adds docker push make targets.

Additionally it adds additional steps in the tag event pipelines in the drone file.

Questions

Will the MacOS build target have docker installed in it in order to run builds. Additionally, do I actually need to run these builds? Docker for Desktop, MacOS images on intel (which I believe the builder here is that) get tagged as linux + amd64, which would be the same as the kubernetes builds.

Testing

Tested that the new Makefile targets work properly by running them locally.

The drone changes were not tested locally due to not being able to run drone exec with kubernetes pipelines. I am open to suggestions on testing drone pipeline changes before merging to master.

[wadells]

Consider moving these to their own pipeline, such that we have tag-build-plugins-linux and tag-build-plugins-docker for instance. This should speed up execution via parallelization, and also allow re-running only a single pipeline if it fails.

Questions

Will the MacOS build target have docker installed in it in order to run builds. Additionally, do I actually need to run these builds? Docker for Desktop, MacOS images on intel (which I believe the builder here is that) get tagged as linux + amd64, which would be the same as the kubernetes builds.

I am under the impression docker on mac ran everything inside a linux vm... meaning those images would be the same as the linux images. See the pipeline idea above for how we can publish images once.

Testing

Tested that the new Makefile targets work properly by running them locally.

The drone changes were not tested locally due to not being able to run drone exec with kubernetes pipelines. I am open to suggestions on testing drone pipeline changes before merging to master.

I'd recommend adding a trigger to the new pipeline that will trigger off a push to your branch, and running it there. Do that in a test branch. See gravitational/teleport#10118 for an example.

Because we're publishing to the staging repo here, we don't particularly care if there are some extra images in it. At least, we wouldn't if we had distinct build versioning a la what you set up for houston. If you're going to be pushing e.g a 9.0.2 and we have tag immutability on... you may need to be more careful.

[logand22]

Consider moving these to their own pipeline, such that we have tag-build-plugins-linux and tag-build-plugins-docker for instance. This should speed up execution via parallelization, and also allow re-running only a single pipeline if it fails.

Changed in 6d86bed

Testing

Drone changes tested here: https://drone.platform.teleport.sh/gravitational/teleport-plugins/960/2/3

The push to ECR for the access plugin failed only due to missing the DRONE_TAG env variable due to it not being a tag triggered event. This won't be a problem with the changes made in the above drone file.

[logand22]

This will work for tagged builds. I will followup with a PR that continuously deploys images on push to master. The tracking issue is here: #460