-
Notifications
You must be signed in to change notification settings - Fork 252
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
push image to multiple registry #1079
push image to multiple registry #1079
Conversation
726270b
to
4a9bb83
Compare
0b64928
to
f44d5c1
Compare
Signed-off-by: Sarath Chandra Oruganti <[email protected]> Signed-off-by: Sarath Chandra Oruganti <[email protected]>
Signed-off-by: Sarath Chandra Oruganti <[email protected]> Signed-off-by: Sarath Chandra Oruganti <[email protected]>
Signed-off-by: Sarath Chandra Oruganti <[email protected]>
9e59a2a
to
60045e6
Compare
I made a release on my fork and here are the jobs Github packages: I created a tag v17.0.2 and here are the packages; Docker Hub: |
uses: hands-lab/dockle-action@v1 | ||
with: | ||
image: ${{ inputs.source_registry }}/${{ inputs.source_image }} | ||
exit-code: "0" |
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.
Ignoring error current need to change to 1 so that we will stop releasing image to docker hub. need suggestion.
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.
You mean we needn't to sync images to dockerhub in a scan image action?
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.
I think we can continue the scan regardless the scan result.
Let's keep it as 0
docker run --rm \ | ||
quay.io/skopeo/stable:latest \ | ||
copy \ | ||
--all \ |
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.
Might have to add --additional-tag "latest" that creates a latest tag while copying currently it is not copying, need suggestion.
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.
it's ok to leave the latest on ghcr only, we can add a note in the repo's readme saying users can fetch latest image from ghcr if they want .
And of course sync the latest to dockerhub is also reasonable
password: ${{ secrets.REGISTRY_PASSWORD }} | ||
registry: ghcr.io | ||
username: ${{ github.actor }} | ||
password: ${{ secrets.GITHUB_TOKEN }} |
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.
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.
As far as I know of I am using GITHUB_TOKEN only which will restrict permissions defined in the actions. I referred to the following document. I allowed the write permissions globally on a repo, and use this clause in actions
permissions:
contents: read
packages: write
Let's check if this works! if not we can create a secret GH_TOKEN and use it.
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.
all right, looks like GITHUB_TOKEN is created automatically for each action and I need to create one manually
@sarathchandra24 Thanks for the great effort, I'm going to add you as maintainer |
Signed-off-by: Sarath Chandra Oruganti <[email protected]>
* push image to multiple registry Signed-off-by: Sarath Chandra Oruganti <[email protected]> Signed-off-by: Sarath Chandra Oruganti <[email protected]> * github actions permissions Signed-off-by: Sarath Chandra Oruganti <[email protected]> Signed-off-by: Sarath Chandra Oruganti <[email protected]> * fluentd multi registry image push Signed-off-by: Sarath Chandra Oruganti <[email protected]> * Limit build to PR changes for certain files Signed-off-by: Sarath Chandra Oruganti <[email protected]> --------- Signed-off-by: Sarath Chandra Oruganti <[email protected]> Signed-off-by: Sarath Chandra Oruganti <[email protected]> Signed-off-by: Paul Smith <[email protected]>
type=ref,event=branch | ||
type=ref,event=pr | ||
type=ref,event=tag | ||
type=semver,pattern={{version}} |
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.
There is a problem here that the fluent-operator and fluent bit have different version, and in this action it use the tag of fluent-operator to build fluentbit images:
when we released fluent-operator v2.8.0, the fluentbit remains 2.2.2, but fluent-bit:v2.8.0 is built instead
and this is the cause of #1178
The make file should be used to build fluentbit images instead https://github.com/fluent/fluent-operator/blob/v2.8.0/Makefile#L3
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.
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.
hmm, let me know if my understanding is correct.
If we are releasing a tag suppose v2.8.0, it is building three images fluentd:v2.8.0, fluent-operator:v2.8.0 and fluent-bit:v2.8.0. As per the workflows, all the images are using tags to release new images.
Do we need to separate them; i.e. are these images having different build and release cycles?
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.
If we are releasing a tag suppose v2.8.0, it is building three images fluentd:v2.8.0, fluent-operator:v2.8.0 and fluent-bit:v2.8.0. As per the workflows, all the images are using tags to release new images.
Do we need to separate them; i.e. are these images having different build and release cycles?
@sarathchandra24 Yes, we need to separate them. The tag of this project should only be used to build fluent-operator while the fluentbit and fluentd have separate tags as defined in the makefile:
fluentbit:
https://github.com/fluent/fluent-operator/blob/master/Makefile#L3
fluend:
https://github.com/fluent/fluent-operator/blob/master/Makefile#L5
Push images to multiple registries; images: fluentbit, fluent-operator
What this PR does / why we need it:
Current system is pushing images to only single registry: Docker Hub;
We want to push images to other registries too; to solve this we are pushing every image to GitHub Container Registry and then we only release image to docker hub if they are changes towards master or tags.
This is a new PR for the requested changes in #1071
Which issue(s) this PR fixes:
Fixes #1068
Does this PR introduced a user-facing change?
Additional documentation, usage docs, etc.: