GitLab now has nice feature called "Releases". You can define "release" as combination of "tag + some description + some URLs" and it will be shown on "Releases" and "Tags" pages of your project. GitLab doc says:
we recommend doing this as one of the last steps in your CI/CD release pipeline
But, wait! CI/CD job by default has no access to API calls or write to git repository. We can configure "deploy token" or "deploy key" for access to repository and use them (via "secret variables") in build scripts. But neither "deploy token", nor "deploy key" give access to API.
So, we can't create release from CI/CD job using its environment variables, we can't use deploy tokens, we can't use deploy keys. So, what exactly GitLab suggests us to do when it says: "we recommend doing this as one of the last steps in your CI/CD release pipeline" ?
To authorise access to the GitLab API, you need to provide the base URL of your GitLab instance. If you're a GitLab.com user, the base URL is https://gitlab.com .
GitLab's integrated CD solution allows you to ship code with zero-touch, be it on one or one thousand servers. GitLab helps automate the release and delivery of applications, shortening the delivery lifecycle, streamlining manual processes, and accelerating team velocity.
This previous question highlighted the same issue, pointing out you need to access in your CI/CD release pipeline to (from doc)
- either OAuth2 tokens
- Personal access tokens
- Session cookie
This is not limited to release.
As seen in gitlab-ce issue 61108: "Allow tags to be managed with CI_JOB_TOKEN
"
However, it turns out that tags cannot be removed by simply using the
CI_JOB_TOKEN
.
Instead I would need to have create an access token and pass this as CI variable to be able to call this API from within the CI jobs.
Other examples:
However, it turns out the call to this REST API does not work with the
JOB_TOKEN
header but only with thePRIVATE_TOKEN
.
Is this limitation intended?I don't want to maintain extra Private tokens just for manipulating the assets of the release.
That means for now (June 2019), maintaining an extra Private token, and passing it as CI variable might be the only available workaround, pending those issues to be resolved.
That would use, I supposed, a masked variable (GitLab 11.0+)
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With