This repository has been archived on 2024-08-20. You can view files and clone it, but cannot push or open issues or pull requests.

115 lines
4.7 KiB
Markdown
Raw Permalink Normal View History

# Release Uploader for Gitlab
2019-05-30 14:35:35 +02:00
Creating releases on Gitlab seems to work only via the REST API.
This Python script handles the upload of a release file, the creation of
the required release tag in the repository and the creation of the actual
release referring to both the tag and the file.
It supports commandline options and an input file, adjusted to be used in
Gitlab CI scripts.
## Usage
wn@tron:~/workspace-python/gitlabreleaseuploader [master ≡]$ ./gitlabreleaseuploader.py -h
usage: gitlabreleaseuploader.py [-h] --privateToken PRIVATETOKEN --projectId
PROJECTID --projectUrl PROJECTURL --file FILE
[--releaseName RELEASENAME]
[--releaseTag RELEASETAG]
[--releaseTagTarget RELEASETAGTARGET]
[--createReleaseTag]
[--description DESCRIPTION]
[--releaseInfoFile RELEASEINFOFILE]
2020-02-28 19:34:31 +01:00
[--caBundle FILE_WITH_CA_CERTIFICATES_TO_TRUST]
[--instanceUrl INSTANCEURL] [--verbose]
Gitlab Release Uploader
optional arguments:
-h, --help show this help message and exit
--privateToken PRIVATETOKEN, -p PRIVATETOKEN
Private token to access Gitlab
--projectId PROJECTID, -i PROJECTID
ProjectID of the related project
--projectUrl PROJECTURL, -u PROJECTURL
URL of the related project at Gitlab
--file FILE, -f FILE File to be released
--releaseName RELEASENAME, -n RELEASENAME
Name of the release
--releaseTag RELEASETAG, -t RELEASETAG
Tag of the release in the repo
--releaseTagTarget RELEASETAGTARGET, -T RELEASETAGTARGET
Commit or branch the tag should point to
--createReleaseTag, -c
Shall the release be created here
--description DESCRIPTION, -d DESCRIPTION
Description of the release
--releaseInfoFile RELEASEINFOFILE, -F RELEASEINFOFILE
File containing JSON object with release info (release
tag, create release tag, description
--instanceUrl INSTANCEURL, -I INSTANCEURL
URL of your gitlab instance
2020-02-28 19:34:31 +01:00
--caBundle FILE_WITH_CA_CERTIFICATES_TO_TRUST, -B FILE_WITH_CA_CERTIFICATES_TO_TRUST
--verbose, -v verbose output
wn@tron:~/workspace-python/gitlabreleaseuploader [master ≡]$
### Without release info file:
gitlabreleaseuploader.py -p PRIVATE_TOKEN -i PROJECT_ID -u PROJECT_URL
2019-05-30 15:45:48 +02:00
-f FILE_TO_BE_RELEASED -n RELEASE_NAME
-t RELEASE_TAG -T RELEASE_TAG_TARGET -c
-d RELEASE_DESCRIPTION -I INSTANCE_URL
### With release info file:
Release Info File:
2019-05-30 15:45:01 +02:00
{
2019-05-30 15:45:48 +02:00
"releaseTag": "v1.5",
"createReleaseTag": "true",
"releaseName": "Sixth release of the uploader",
2019-07-10 12:39:02 +00:00
"description": "Now with CI script and automatic release upload (hey, eat your own dogfood)"
}
Command:
2019-05-30 15:45:01 +02:00
gitlabreleaseuploader.py -p PRIVATE_TOKEN -i PROJECT_ID -u PROJECT_URL
2019-05-30 15:45:48 +02:00
-f FILE_TO_BE_RELEASED -F RELEASE_INFO_FILE
2019-05-30 15:52:10 +02:00
### Use in CI script
The PRIVATE_TOKEN should not be entered directly into the CI script but added as protected a CI variable to you particular project.
Then add the following stage into your CI script:
release:
stage: release
image: registry.gitlab.com/wolutator/base-build-env
only:
- release
script:
- gitlabreleaseuploader.py -p $PRIVATE_TOKEN -i $CI_PROJECT_ID -u $CI_PROJECT_URL
-f gitlabreleaseuploader.py -F info.json -T $CI_COMMIT_REF_NAME
2019-05-30 16:07:35 +02:00
Note, please: this stage definition is for a docker worker. It uses my ``base-build-env`` image, which already contains the
2019-05-30 15:55:06 +02:00
uploader script. However, it is no problem to use the uploader script also in different environments. It just depends on the
2019-05-30 16:07:35 +02:00
``Requests`` package.
Note too, please: this job is releasing the ``gitlabreleaseuploader.py`` script itself, so you see the name of the script twice in the CI script. Don't be confused, the option ``-f`` gets the file to be released.
2019-05-30 15:55:06 +02:00
2019-05-30 15:52:10 +02:00
Most information are taken from CI builtin variables, the tag name, release name and release description should be stored in
2019-05-30 15:55:06 +02:00
the release info file (here: ``info.json``), which is under version control.
2019-05-30 15:52:10 +02:00
To avoid releasing a file with everything single push to an arbitrary branch, add the ``only`` block.