opentelemetry-collector
opentelemetry-collector copied to clipboard
open-telemetry
One-click official release of the latest "auto-full-test"-ed image to Docker hub
When a release is created and a commit is tagged by a version number in Github it currently triggers a build and uploads the resulting image to Dockerhub. We want this to also verify that the commit is already tagged as "auto-full-test".
Once we gain confidence we may perform these releases of "auto-full-test" fully automatically to Dockerhub.
So the only requirement here right now is that CI only pushes new images when it builds a commit that is tagged with both the version to be released and static :"auto-full-test". Does this mean we'll delete old auto-full-test tags? Or will auto-full-test just be a piece of text present in the commit message? Also, who/how will commits be tagged with auto-full-test text?
So the only requirement here right now is that CI only pushes new images when it builds a commit that is tagged with both the version to be released and static :"auto-full-test". Does this mean we'll delete old auto-full-test tags?
Yes. We don't "delete" the old tag. When you apply the same tag to a new commit, doesn't the old commit automatically lose the tag?). Alternatively, we could use unique tags (append timestamp to tag name), but I don't see much need for that. We only need to know the latest fully tested commit.
Also, who/how will commits be tagged with auto-full-test text?
"auto-full-test" will be set by the full test suite after the tests are successful: https://github.com/open-telemetry/opentelemetry-collector/issues/1028
Yes. We don't "delete" the old tag. When you apply the same tag to a new commit, doesn't the old commit automatically lose the tag?)
No, git tags don't automatically move between commits and only a single commit can be tagged with a single tag. Tags can be deleted and then re-used however which should be trivial if we plan to automate the flow. ot sure if deleting and re-creating could have
"auto-full-test" will be set by the full test suite after the tests are successful: #1028
This implies CI will have write access to the repo which currently is not the case. This'll open up an attack vector against the repository which may be fine but worth discussing.
Another alternative would be for the full test suite to trigger release CI job on success instead of pushing new tags to git.
Tags can be deleted and then re-used however which should be trivial if we plan to automate the flow.
That's what I meant. :-)
This implies CI will have write access to the repo which currently is not the case. This'll open up an attack vector against the repository which may be fine but worth discussing.
Good point. I am open to alternatives.
Another alternative would be for the full test suite to trigger release CI job on success instead of pushing new tags to git.
So you are suggesting that the first job builds the Collector, runs quick tests but does not publish the image to Dockerhub. The first job triggers the second job which runs full test suite and if it passes published the image to Dockerhub? Is that the suggestion?
Question: can we build the Docker image in the first job and pass it to the second job as-is without building it again in the second job? This will ensure we build the image once and all tests are run against that image and it is the exact image that is published to Dockerhub.
So you are suggesting that the first job builds the Collector, runs quick tests but does not publish the image to Dockerhub. The first job triggers the second job which runs full test suite and if it passes published the image to Dockerhub? Is that the suggestion?
Yes, something like this. We can chose any variation of this provided it satisfies requirements to run full test suite before publishing an image.
Question: can we build the Docker image in the first job and pass it to the second job as-is without building it again in the second job? This will ensure we build the image once and all tests are run against that image and it is the exact image that is published to Dockerhub.
Yes. If both jobs run inside the same CircleCI build, we can easily pass it as an artifact to the next job.
If the jobs run as separate builds, the first job could build and publish a "pre-release" image to docker hub and then trigger the second job. The second job could fetch the image, test it, tag it as certified and push it to the same repo or a different one.
@owais can you please update issue description with your proposed solution instead of "auto-full-test" tag and also update https://github.com/open-telemetry/opentelemetry-collector/issues/1028 correspondingly?
@flands I am removing this from this milestone since we won't have time to do it. Will be done later.