Performance about ecr-login-action

[lilliSeBe]

Hmm let me ask the team and get back.

[elgohr]

I would like to wait on GitHub for that. As I heard there could be a way of releasing an action as a GitHub package. In this way the multistage build can stay as is. Maybe @lilliSeBe could help on that? :-)

[miskander]

Hey @elgohr! I’m on the Actions team, @lilliSeBe send me this thread so I wanted to address your question. Right now the only way to release an action to the marketplace or in general for use outside of a git reference is via creating a Release, you can see more info here https://help.github.com/en/actions/building-actions/publishing-actions-in-github-marketplace#publishing-an-action. What you mentioned above about Actions being published instead to GitHub Packages is something we’re interested in, but at this moment is not possible and we don’t have an estimate of when it would be implemented.

Let me know if that addresses your questions and if I can be of any other help.

[bryanmacfarlane]

I'm taking a 👀

[lilliSeBe]

@elgohr - I think we were talking about this
Does that help?

[elgohr]

@lilliSeBe at the moment actions are published as GitHub releases. In this way they're taken on run and executed (which makes a multi-staged Docker build run again on every execution). I thought we where talking about a way to build Docker images to GitHub packages and use a package instead of a release. Or did I get that wrong?

[lilliSeBe]

Ahh 😄 - instead of referring to a Git reference for an action, you could also directly refer to a docker image: https://help.github.com/en/actions/reference/workflow-syntax-for-github-actions#example-using-a-docker-hub-action

[elgohr]

And this not for the users (as in the link), but when people want to publish a new version of an action (https://help.github.com/en/actions/building-actions/publishing-actions-in-github-marketplace#publishing-an-action). At the moment this works with releases. So action version x would be docker ref y.

[lilliSeBe]

Hey @elgohr sorry this got a bit lost! But you're right with the last statement.
Also if you have more questions, you can also always contact the GitHub Enterprise Support. As the team consist of engineers, they will be quicker and better in helping you out than me 😛

[elgohr]

Hi @lilliSeBe, this action is not related to any Enterprise... Don't these engineers work on GitHub? 😁
So will this change?
At the moment there would be a workaround, but I guess that's not how GitHub would like to publish actions (elgohr/Publish-Docker-Github-Action#78 (comment))?

[elgohr]

Hey @miskander , do you have any suggestions for this issue?
As you can see in the Dockerfile, it's a multi-staged build (including the tests).
In this way the tests are executed every time that the action runs.
The downside is, that they run every time the action runs :D

To me there are two solutions at the moment:

• Publish a Docker image that inherits this image:latest (Pro: Faster as prebuild; Cons: This somehow bypasses the release process of actions)
• Externalize the tests from the Dockerfile (Which I would like to avoid as the "integration testing" part of the tests will get loose)

[bryanmacfarlane]

Have you considered publishing with a label and using container and label in action yaml file? https://help.github.com/en/actions/building-actions/metadata-syntax-for-github-actions#runs-for-docker-actions

[elgohr]

Hey @bryanmacfarlane , sure (elgohr/Publish-Docker-Github-Action#78). To me this is a good workaround, but totally bypasses the marketplace...
As this action deals with login data, I would like to give people as much trust as possible. So I would prefer using the marketplace.

[bryanmacfarlane]

I think you can still do the marketplace. You create a release, supply a tag (e.g. v1.2.3) and check to publish / register it in market place. The release is still creating that tag. When someone has a workflow yaml that does a - uses: elgohr/[email protected] the runner will pull the actions repo contents at the ref v1.2.3 (which effectively will just be an action.yml) which has instructions to pull the published image specified in runs:/image:, set the envvars and run it.

So when creating a release (even if published to the marketplace), the key piece to the runner is the repo tag. (it doesn't query release apis by names etc.)

Does that help?

[elgohr]

When I got you correct, I would use https://help.github.com/en/actions/building-actions/metadata-syntax-for-github-actions#example-using-public-docker-registry-container for pointing to elgohr/[email protected] on (for example) DockerHub?
The release itself builds elgohr/[email protected] and pushes it (hopefully) to DockerHub.
When things go bad I would end up with a broken action in production.
Sounds like a chicken-egg-problem to me.

By the way, it would be great to have more documentation for runs.image.
Is it possible to use GitHub packages in here?

[bryanmacfarlane]

runs image is covered here: https://help.github.com/en/actions/building-actions/metadata-syntax-for-github-actions#runs-for-docker-actions

The process would have a tag in your repo named 1.2.3 which references a sha with an actions.yml file that references the container published with the 1.2.3 tag.

Not sure I understand the chicken and egg problem. If 1.2.3 is bad, then anyone referencing 1.2.3 would get the bad change. Anyone referencing 1.2.2 and earlier would continue to work. The same would happen with packages. Maybe I'm missing something.

[elgohr]

https://help.github.com/en/actions/building-actions/metadata-syntax-for-github-actions#runs-for-docker-actions doesn't say anything about GitHub packages 🤔

If people use fixed versions: yes, they have no problem when master breaks.
If they don't, they do.

Chicken-Egg: In actions.yml I would have to name an image in a registry. So I would have to
(a) prebuild and publish a commit to a registry. After that create a release, which might differ from the published code in the registry, and put the tag into the release. In this way I would already know that the image is present in the registry, but as code might differ it's not my understanding of a release.
(b) say YOLO and put a non-existing tag name, which might be published by a successful build from the release to the registry, into the actions.yml
As the release build might fail, I could end up with an action.yml pointing to nowhere.

[elgohr]

At the moment I'm thinking about releasing my actions as

runs: 
  using: 'docker'
  image: 'docker://myaction:latest'

and release it just once in a lifetime, as latest will be updated.

Why?
Because in context with Dockerfiles the marketplace releases look more and more like a fig-leaf to me. As soon as the Dockerfile installs something via a package manager, this may change the tested state, which was published to the marketplace initially (let's say the Dockerfile does apk add jq, it might be tested with v0.0.1 of jq, but when jq changes it takes the latest version).
This is not the case when using containers from a registry. When using a registry, I come back to the chicken-egg problem (#6 (comment)).

[elgohr]

@abrkn could you please give feedback regarding https://github.com/elgohr/ecr-login-action/releases/tag/1.0.0 ?

[elgohr]

I guess we can see this closed...