-
Notifications
You must be signed in to change notification settings - Fork 32
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[CI]: CI pipeline #54
Conversation
I need your review:
I'm afraid I'm not an admin of this particular repo therefore I cannot assign reviewers. |
Co-authored-by: cachedout <mike.place@elastic.co>
@@ -1,4 +1,4 @@ | |||
REPOSITORY := docker.elastic.co/beats-dev | |||
REPOSITORY ?= docker.elastic.co/beats-dev |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is the only change in the code to be able to set the repository where the docker images can be pushed, by default as used to be, but as we will be using the staging
stage, then this will help to generate docker images on a PR basis which can be consumed for testing purposes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
This repo is tied in with membership in https://github.com/orgs/elastic/teams/beats-contributors if you want to join. |
This implies that this repo will need to start doing some tagging. As of now we've been pushing new images whenever master changed. And we really only changed master when new Go releases were available. I'm not against requiring tagging, but we should have a plan for it if we go this route (when do we tag, what do the tags mean, how do we convey the tag in the image metadata). |
@andrewkroh , thanks for the details, I'm not really familiar with the release process for this project, I was just thinking the tag could be matching the go version, but there are certain questions as you stated that they are required to be addressed beforehand. What do we do from here? |
as Victor said, the most logical tag is the Go version. Using tags adds the possibility to compile with any images generated for a previous Go version in case we need it for some test, or we want to compile with several Go versions at some point. |
To be clear I was talking about git tagging, which is what I assume is meant in "on tag based to the default location". Any build of the repo produces images for multiple Go versions. Those images have docker tags containing the Go version and the cross-compiler architecture (see build tags). Perhaps the path forward is to not introduce git tagging into the image push process at this time. And setup the job to push changes from master to the default location in the Makefile. I think we can get the same ability to reproduce old builds if we add an additional docker tag (without git tags) that contains a time component (e.g. 1.10.8-main-20191124). Then if I need to exactly reproduce some old Beats build for whatever reason, we can use the time tagged docker images from the time of the original build. The images already contain docker labels following http://label-schema.org/rc1/ that contain this repo's commit ID in case we need to know the exact Dockerfiles that went into producing the images. If we do want to use git tags to trigger the image pushes then we should
|
To keep it simple, I'll remove the |
…ature/ci * 'feature/ci' of github.com:v1v/golang-crossbuild: Apply suggestions from code review
c5cc234 is now the new behaviour. NOTE: if we merge this particular PR then the automation to push those docker images will happen immediately. |
I'll merge this particular PR as soon as the github setup is in place (webhooks and permissions) |
Alright, we got all the required webhooks and service accounts in place to run in the CI! As soon as the build gets green then I'll merge it |
For the record ead3be2 removed the issues with the push.* which it's not required anymore at all (for furtherh details please refers to the infra docs). Already tested locally: $ docker tag docker.elastic.co/observability-ci/fpm:1.11.0 docker.elastic.co/observability-ci/fpm:test
$ docker push docker.elastic.co/observability-ci/fpm:test
The push refers to repository [docker.elastic.co/observability-ci/fpm]
aa5033bd89aa: Pushed
dc29c4af552e: Pushed
0f7b4d7b24a5: Pushed
7deb88e599ba: Pushed
8354d5896557: Mounted from observability-ci/golang-crossbuild
test: digest: sha256:1c8721bf3d8095878b02855a8c3d90a6c6d380de49c2483929e68323df487687 size: 1368 |
What
Enable CI pipeline to build and push the docker images.
The push event works for:
Tasks
Test
REPOSITORY=docker.elastic.co/observability-ci make build
REPOSITORY=docker.elastic.co/observability-ci make push