PoC: Tech evaluation for gitlab-releaser
Overview
Tech evaluation for the new gitlab-releaser
CLI tool see #9 (closed)
This MR is not for merging but rather create smaller pieces of work that can be gradually merged.
Related Issues
MR List
-
Create gitlab-releaser module !4 (merged) -
Add GitLab client !5 (merged) -
Support create
command and integrate with the client !6 (merged)
Go version
Using latest Go version 1.13.7
as of 2020-02-07 https://golang.org/dl/
Go modules
Go modules is the supported dependency management tool. Used in other Go projects like gitlab-pages
and gitlab-runner
CLI Framework
I decided to use https://github.com/urfave/cli given that gitlab-runner also uses it. I considered using cobra due to its popularity but it would be easier for everyone to use the same tools used in other projects.
Project layout
Inspired by https://github.com/golang-standards/project-layout to structure the code. I really like the structure proposed there, it makes it easier to find a file. Also the cmd/projec_name
structure is great to namespace binaries/runnable code inside this project. I have followed this structure in the past and I can vouch for it!
TL;DR
rootDir/
cmd/ # distributable binaries / helper cmds
projectName/
main.go
helperCMD/ # e.g. data generation or preprocessing, etc...
internal/ # packages used by this project only, not meant to be imported outside of this project
package1/...
package2/...
pkg/ # packages that can be imported by other packages outside of this project
importablePackage1/...
vendor/ # keep all dependencies committed for fasted build times and dependency consistency
tests/ # used for end-to-end tests or to share testing dependencies inside this package
GitLab Releaser commands an options
gitlab-releaser
will accept at a minimum the following command and options
Command:
-
create
-gitlab-releaser create [FLAGS]
Flags:
Some of these flags will try to grab the value from an Environment Variable but they can be overridden using the flag explicitly. For a list of available variables inside GitLab CI see Predefined environment variables
Flag name | Required | Description | From CI Environment Variable | CI_VARIABLE_NAME |
---|---|---|---|---|
--name |
Yes | The release name. This will be shown as a title in the releases list. | No | - |
--description |
Yes | The description of this release. Only text description for now. | No | - |
--token |
Yes | The GitLab API access token | Yes | CI_JOB_TOKEN |
--project-id |
Yes | The project ID | From Environment Variable | CI_VARIABLE_NAME |
--gitlab-server |
Yes | GitLab server instance e.g. https://gitlab.mydomain.com
|
Yes | CI_SERVER_URL |
--tag-name |
Yes | The tag where the release will be created from. | Yes (if present) | CI_COMMIT_TAG |
--ref |
No | If tag_name doesn’t exist, the release will be created from ref. It can be a commit SHA, another tag name, or a branch name | Yes (if present) | CI_COMMIT_SHA |
Tech Evaluation Checklist
-
Add the command gitlab-releaser create
and support-name
and-description
-
Implement the POST /projects/:id/releases
endpoint of the Release API https://docs.gitlab.com/ee/api/releases/#create-a-release -
Add some unit tests -
Simple build pipeline