Use Gitlab's CI_JOB_TOKEN

[ngotchac]

Is your feature request related to a problem? Please describe.

So far, to push a release to Gitlab, one needs to setup a new API token, and configure the pipelines with it. However, there is already a job token available, via the CI_JOB_TOKEN env-var. It could be used to create a new release, but needs a special header to be set.

Right now, goreleaser uses gitlab.NewClient, which registers a PrivateToken which sets the PRIVATE-TOKEN header value.

What should be possible, is to call NewJobClient instead if the CI_JOB_TOKEN is present (or via an option I guess), which would mostly remove the need to manage an API token.

[caarlos0]

cc/ @mavogel wdyt?

[caarlos0]

also, related to #2738 ?

[ngotchac]

Okay so actually I tried and there's only a last piece missing here... So for Gitlab, gorelease uses the Release link API right now to add the assets to a given release, after it was created. However, using JOB-TOKEN for this API isn't supported yet, cf. https://gitlab.com/gitlab-org/gitlab/-/issues/250819
So one option for goreleaser would be to upload the files before creating the release, and passing the links there directly, but this means that a release can't be appended new files. Or wait for Gitlab to fix their issue...

[caarlos0]

I would say to wait then...

[dolmen]

I was about to report this after #2738 and I experimented more with GitLab CI and goreleaser.

I thought the GitLab tasks should fallback to CI_JOB_TOKEN if GITLAB_TOKEN is not defined, but reading @ngotchac's comment that doesn't seem to be that easy.

[caarlos0]

maybe this is fixed on v1.3 which supports the generic registry? #2006 #2745

[matteosilv]

I tried to build and run the v1.3 on gitlab with use_package_registry: true and a patch i wrote to use CI_JOB_TOKEN as @ngotchac suggested, but goreleaser is still using the link api and fails

[caarlos0]

would #2993 help?

[ngotchac]

would #2993 help?

Hey! Thanks for the update, I think it's going in the right direction, but it's still not working :/ This is mostly on Gitlab's end, since their Release Link API is still not available via thei CI_JOB_TOKEN. I built an example repo, with the failed pipeline you can check here: https://gitlab.com/ngotchac/goreleaser-tester/-/jobs/2247096351

The issue is this one: https://gitlab.com/gitlab-org/gitlab/-/issues/250819
A solution however would be to create a release with all the links directly in the release, and if there is already one, just delete it before creating a new one

[caarlos0]

I think I rather wait for gitlab to fix on their end...

[arusso]

would #2993 help?

Hey! Thanks for the update, I think it's going in the right direction, but it's still not working :/ This is mostly on Gitlab's end, since their Release Link API is still not available via thei CI_JOB_TOKEN. I built an example repo, with the failed pipeline you can check here: https://gitlab.com/ngotchac/goreleaser-tester/-/jobs/2247096351

The issue is this one: https://gitlab.com/gitlab-org/gitlab/-/issues/250819 A solution however would be to create a release with all the links directly in the release, and if there is already one, just delete it before creating a new one

Looks like this issue was fixed and released with 15.1 yesterday.

[caarlos0]

nice, should we reopen and merge #2993 then?

[arusso]

I wont be on 15.1 for a few more weeks but happy to test once I get there.

[caarlos0]

amazing @arusso , thanks!

[drewstinnett]

Selfishly interested in this one, so I went ahead and gave it a test against gitlab.com (currently running >v15.1) and it works! Here's the project I tested with:

https://gitlab.com/drewstinnett/goreleaser-ci-test

And the subsequent successful GitLab run:

https://gitlab.com/drewstinnett/goreleaser-ci-test/-/jobs/2697620483

I'm happy either way, but would you consider auto-detecting if the CI_JOB_TOKEN is in use, instead of requiring an additional config parameter? I was thinking something like:

if token == os.Getenv("CI_JOB_TOKEN") {

instead of

if ctx.Config.GitLabURLs.UseJobToken {

This is what I have in my .goreleaser.yaml now, which seemed to do the trick, but would be nice if there was one less param to change:

gitlab_urls:
  use_package_registry: true
  use_job_token: true

Happy to submit a PR or whatever, also happy to just use the way you already have it. Thanks as always for your awesome work

[caarlos0]

I'm happy either way, but would you consider auto-detecting if the CI_JOB_TOKEN is in use, instead of requiring an additional config parameter?

isn't it always set in gitlab ci? (honest question, I don't really know)
if it isn't, yes, sounds like a good plan.

[drewstinnett]

Yup! It's an automatic env var in all GitLab CI runs, so should be pretty safe I think. It's really cool to not have to have the long lived token shoved somewhere, so hoping this is a good long term thing

[caarlos0]

so, the reason for that config is that this pr would not work on older gitlab versions, so probably we shouldn't auto use it if its always set - including old gitlab versions...

[drewstinnett]

I gotcha, that's a good point, thanks @caarlos0!

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.