Running within Gitea Actions creates releases on github.com

[milanaleksic]

I am asking myself what I'm doing wrong, but it could be that the goreleaser is at this time (still?) not capable of creating Gitea releases while running within Gitea Actions.

I have configured my .goreleaser.yaml file with gitea_urls:

gitea_urls:
  api: https://git..../api/v1
  download: https://git....

But it seems that I can't create releases since Gitea Actions always attempts this:

  ⨯ release failed after 42s                 error=scm releases: failed to publish artifacts: POST https://api.github.com/repos/***/tailscale_check/releases: 401 Bad credentials []

Thus, my question: is there a way to direct goreleaser to push release to gitea, not github, since the repo and CI/CD are all hosted on the Gitea platform?

[caarlos0]

this looks like a bug... can you create and share a minimal reproducible example of it?

[GoryMoon]

This is because Gitea Actions auto sets the GITHUB_TOKEN to it¨s token.
When adding the following part to the action it complains about double tokens:

        env:
          GITEA_TOKEN: ${{ secrets.GITEA_TOKEN }}

  • loading environment variables
    • using token from "$GITHUB_TOKEN"
    • using token from "$GITEA_TOKEN"
  ⨯ release failed after 0s                  error=multiple tokens found, but only one is allowed: GITHUB_TOKEN, GITEA_TOKEN

I've tried to set the GITHUB_TOKEN to empty values but that doesn't work.
I've also tried to set the github_token in the config but looking at the code it' only used when the environment variable isn't present.

env_files:
  github_token: /dev/null

It would be nice if you could configure it to a specific service instead of determining it from the token environment.
Or at least make it optional to manually set the service and use the automatic way by default.

[caarlos0]

IMHO its weird that gitea enforces a token that is not theirs... maybe open an issue to them to allow cleaning it up?

that said, we could add a "hint" or something, to prefer using one or another...

[GoryMoon]

There is an issue for it at https://gitea.com/gitea/act_runner/issues/75
I guess the reason behind it is to support as many of the existing Github Actions as possible
It also looks like it's that part is from the underlying system that is made to run Actions locally https://github.com/nektos/act

[caarlos0]

Could you check #3910 ?

[caarlos0]

Could you check #3910 ?

[milanaleksic]

Could you check #3910 ?

Thank you @caarlos0 , that PR would indeed be the short & simple solution for this problem.

I can't speak in the name of Gitea people, but I can see where they are coming from: github actions and the act project helps bring a massive amount of OOTB ready for usage actions. At the same time, an ability to have some kind of explicitness during the process of choosing the integration within the goreleaser might also benefit this project long-term while all these CI/CD services fight for the market share.

The only thing I'd add is that (for me at least) it would make sense to move the setting from an env variable setting override into the YAML since env variables are now becoming a not "precise enough" way to implicitly detect the desired target CI/CD configuration and I'd try to keep things simple and the ENV namespace free of decision making variables. If you tell me that I can put the value meant to be read from GORELEASER_FORCE_TOKEN into YAML, I will be ecstatic, definitely 😄.

[caarlos0]

sorry I forgot to reply this...

I think that if you put it in the root env section it'll pick it up, yes...

In any case, since this fixes the issue, maybe we could make it a config too... can you open an issue about it?

Thanks!

[milanaleksic]

Thank you, the PR you merged fixed the reported issue!