goreleaser Use Gitlab's CI_JOB

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.

Dec 06 '21 16:12 ngotchac

cc/ @mavogel wdyt?

Dec 06 '21 19:12 caarlos0

also, related to https://github.com/goreleaser/goreleaser/issues/2738 ?

Dec 06 '21 19:12 caarlos0

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...

Dec 06 '21 21:12 ngotchac

I would say to wait then...

Dec 07 '21 01:12 caarlos0

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.

Dec 07 '21 08:12 dolmen

maybe this is fixed on v1.3 which supports the generic registry? #2006 https://github.com/goreleaser/goreleaser/pull/2745

Jan 07 '22 01:01 caarlos0

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

Jan 14 '22 08:01 matteosilv

would #2993 help?

Mar 19 '22 20:03 caarlos0

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

Mar 24 '22 16:03 ngotchac

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

Apr 02 '22 13:04 caarlos0

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.

Jun 23 '22 17:06 arusso

nice, should we reopen and merge #2993 then?

Jun 23 '22 17:06 caarlos0

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

Jun 24 '22 00:06 arusso

amazing @arusso , thanks!

Jun 24 '22 01:06 caarlos0

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

Jul 08 '22 16:07 drewstinnett

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.

Jul 08 '22 17:07 caarlos0

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

Jul 08 '22 17:07 drewstinnett

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...

Jul 08 '22 17:07 caarlos0

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

Jul 08 '22 19:07 drewstinnett

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.

Dec 05 '22 13:12 github-actions[bot]

Use Gitlab's CI_JOB_TOKEN