Push git tags as docker tags about publish-docker-github-action HOT 41 CLOSED

@mrfelton Find why it's not like this in #13
What do you think about having the tag of the snapshot as an output?

from publish-docker-github-action.

Ok, then let's do it like that.

@turbo: sounds like an edgecase to me.
At my point of view it would be an actions-feature for running parts of an action sequentially.

from publish-docker-github-action.

yes. But, from my point of view, pipelines need to be well configured to prevent overriding other images.
The expected behavior of this action is to map git tag to docker tag when exists.
In most of cases, the tag is a version number like 2.0 which doesn't conflit with branch names.

from publish-docker-github-action.

from publish-docker-github-action.

Hey, thank you very much.
I'm totally with you. The only concern I have is, that there might be collisions between tags, releases and branches.
When I'm thinking about releases/tags, I would like to freeze things to that moment.
A branch with the same name would override it.
In this way the tag for the only freezed state in this resource (snapshots) is autogenerated and very unlikely for a collision.
If you have a good idea for mitigating the collisions, I would be glad to hear it ☺️

from publish-docker-github-action.

Looks somehow like #18
Do we want to keep the discussion in there?

from publish-docker-github-action.

I'd prefer to see the image snapshots tagged using GITHUB_SHA. That way, we could reference the snapshot tag from other build jobs. As it is now, if you use the snapshot feature, there is no way to know what tag the image was assigned as so impossible to reuse the snapshot in other build jobs.

from publish-docker-github-action.

I think providing the snapshot name as an output would be pretty useful @elgohr

from publish-docker-github-action.

Thanks for this feedback. A solution could indeed be to have tag names such as tag-1.0.0-GIT_SHA (or date).

It would reduce the risk of collisions and allow to reduce the number of tags by not using the snapshot feature. Also users could easily find the image tag associated to a specific release.

from publish-docker-github-action.

A solution could indeed be to have tag names such as tag-1.0.0-GIT_SHA (or date).

That sounds like a possibility for tag builds, but what about branch based builds?

from publish-docker-github-action.

Perhaps you could use something like this:

git describe --abbrev=40 --dirty

from publish-docker-github-action.

So what do you think about doing it like this:

(this table doesn't contain snapshot builds, which would stay like they are)

from publish-docker-github-action.

Snapshot as outputs is here https://github.com/elgohr/Publish-Docker-Github-Action#outputs

from publish-docker-github-action.

No discussion within the last 12 days. I guess it's not that urgent. Can we close this?

from publish-docker-github-action.

I too am looking for this functionality, what's the current state of this?

from publish-docker-github-action.

#24 (comment) would be the proposal. Waiting for feedback

from publish-docker-github-action.

#24 (comment) would be the proposal. Waiting for feedback

Hi! It would be a good compromise indeed.
Then running docker tag my-image:GITHUB_SHA my-image:1.1.0 could be done manually with human control to prevent collisions.

Thanks for this solution, and sorry for not responding before.

from publish-docker-github-action.

I don't know if I agree on explicitely tagging latest, though I may have misread something. What if two actions on two (say) releases are triggered and the first one finishes later? The release tags on the image will be correct, but now an older image is being tagged as latest?

from publish-docker-github-action.

@real34 just rethought a bit.
Couldn't you do the same, when you have snapshots enabled?
In the case of a Release/Tag this would be a push to master + a snapshoted tag.

from publish-docker-github-action.

@turbo please have a look at https://github.community/t5/GitHub-Actions/Prevent-parallel-workflows/m-p/32914/highlight/true#M1305

from publish-docker-github-action.

@elgohr The root problem behind the scenario I've described is that your action would create the latest tag, not that Actions run concurrently. It's the reason other CI's docker actions (e.g. Azure DevOps) have a config option for "also tag latest". A release is a tag already, so I see no reason to automatically include the latest tag. If you do introduce this feature, it'd be nice if you made the latest tag an option. But don't let me hold you up from actually implementing this! After all, I can make my changes in a fork. :)

from publish-docker-github-action.

At the moment it doesn't look like this action needs any change, as you could get everything by configuration already.

from publish-docker-github-action.

Would it be possible to add a flag that allow us to choose the tag.
In our pipeline, we would like to always tag the dev branch 0.0.

from publish-docker-github-action.

@elgohr so what kind of config should we use to have a tag that map the release number?

from publish-docker-github-action.

This doesn't work:

with:
  name: image-name:${{ GITHUB_REF }}

from publish-docker-github-action.

@Sispheor sorry, this isn't possible as the action would need to handle collisions, which is way to complex.

from publish-docker-github-action.

Where is the colision if we are sure to create a new tag?
Why we cannot use this?

elif isGitTag; then
    TAG=$(echo ${GITHUB_REF} | sed -e "s/refs\/tags\///g")

from publish-docker-github-action.

Sorry, I don't get what you're trying to do.
Could you please explain a little more?

from publish-docker-github-action.

I think I want to do what is described in this issue.
When I git tag a version, this tag name is also used as docker tag when I build my image.

In the current code, if a git tag is detected like refs/tags/5.0, we don't tag with 5.0 but latest.
So I replaced the line 67 by the code I shown you and I have the expected behavior.

from publish-docker-github-action.

The point is, that branches with the same name as a release will override the release image and there would be no way to restore it. From a git standpoint I wouldn't see this as the most expected behavior, but on the other hand it prevents to believe in a promise (fix unchangeable image), which isn't fulfilled.

If you want to fix a point in time safely, feel free to use snapshots.

from publish-docker-github-action.

The point is, that branches with the same name as a release will override the release image

Not if the build is triggered on releaes, which is what would actually happen in production. Pushes to branches which happen to have the same name (e.g. from release management) fire separate events.

from publish-docker-github-action.

a tag is seen with a ref that contains the word tags, isn't it? Like refs/tags/5.0.
Which is different from the ref we receive if it's a branch, right? The ref for a branch is like /refs/head/branch_name.

from publish-docker-github-action.

And all go into a registry, which doesn't care which job wrote what.

from publish-docker-github-action.

@turbo how would you ensure that a job, triggering on push, wouldn't override an image, which was pushed by a job that triggered on release?

from publish-docker-github-action.

Sorry, that's your expectation.

At the moment we don't have the problem that people need to care for. And I don't think it's worth introducing, unless there is a usecase that couldn't be covered by using the current implementation.

from publish-docker-github-action.

I wouldn't run any publish actions on push. Maybe run some tests, collect coverage etc. But for me at least, I want pretty much only tags to be "released". latest doesn't mean latest release, otherwise docker registry would attach it automatically to new pushes. It's meaning differs from project to project, sometimes it's a release, sometimes a beta and sometimes not used at all.

I think the best way to do this would be to:

• enable git tags as docker tags (explicit opt-in)
• state in the docs that for this use-case, the user has to make sure not to create conflicting triggers
• make "also tag latest" on option for the action, regardless of tags, triggers or anything else (just like other CIs offer)

from publish-docker-github-action.

Sounds good to me. I would prefer to either use latest on default and use release_name when turned on.

from publish-docker-github-action.

Sounds good to me. I would prefer to either use latest on default and use release_name when turned on.

Sound good, though I might be misinterpreting it. Could you please draw up a small table with examples?

from publish-docker-github-action.

That looks perfect. Whether there should be a way to (optionally) enable both for the "Tag/Release" case, I don't have a strong opinion on, but it might be important to other people's workflow.

from publish-docker-github-action.

Please see https://github.com/elgohr/Publish-Docker-Github-Action#tag_names
https://github.com/elgohr/Publish-Docker-Github-Action/releases/tag/2.7

from publish-docker-github-action.

Can we close this?

from publish-docker-github-action.