dagger / dagger-for-github

GitHub Action for Dagger

Home Page:https://github.com/marketplace/actions/dagger-for-github

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

uses: dagger/dagger

shykes opened this issue · comments

I know we have already discussed naming and have already renamed this repo… I apologize for re-opening this topic but: are we sure we can’t just pick the name “dagger” for the action? When we first discussed this option, the answer was “not possible because dagger/dagger is already taken by the dagger repo itself”. But… couldn’t we move the action’s source to that repo? I guess we would have a top-level action.yaml file and other mild nuisance. But in exchange, everyone gets to write uses: dagger/dagger in their workflows? That DX improvement seems worth it to me :)

What am I missing?

The main argument I see against moving the action to the main dagger/dagger repo is the versioning scheme between dagger and github action. You could argue that they could be the same since they're all part of the same product, but it'd feel strange if we have to make a minor (potentially major?) version bump due to an action change without changing the product. Consecutively, even if there's a minor change in the action, the release would also have to include new dagger binaries without any changes. It feels unnecessarily complex and confusing if we have to do something like this in return of having a better DX in the action name.

As a last comment, I can't recall seeing other projects that handle the action and the product release in the same repo. If there's any, it'd be nice to see how they address my previous concern.

I agree with what @marcosnils said -- GH actions have versioning, releasing and building constraints. Sharing those with our main repo would be challenging.

The most common patterns are:

  • Using an action or actions repo (e.g. pulumi/actions)
  • Using a setup-XX repo, in the same style as actions/setup-go & actions/setup-python (e.g. hashicorp/setup-terraform)
  • <project>/<verb>-action (e.g. docker/login-action, docker/build-push-action, ...)
  • Separate org (e.g. aws-actions/configure-aws-credentials, google-github-actions/setup-gcloud)