Example how this project: deployctl is Continious and automatic released with Gitlab and deployctl.
The build-stage compiles the code into executables, we only need the sripts and readme.md, so we copy to the
For every commit on Gitlab, output will be generate and available for in the review/branchname or master, except on a tag commit of the master.
On a tag commit of the master, the pipeline will generate a staging environment, which can then manually be deployed to the
A release badge is generated by deployctl on a tag-build in the
production environment, when the tag does not contain the following words, case-insensitive:
coded in Markdown, with a link to latest release download page, as:
Building this project is through the Gitlab CI/CD, by defineing the gitlab-ci.yml file. Find below a view of the pipeline:
All files to be included in the release page are copied to the
output-directory and which are uploaded as artifacts after each job to Gitlab.
At the review/staging/production, all files should be in the
output-directory, which are then moved to the release directory by the script.
deploy release command, handles moving the data in the right place according to the:
#Deployment locations DEPLOY_RELEASE_PATH: |- [ "output/", "output/rpm/", "output/dist/" ]
On a production release, depending on
acme.sh will create an certificate for the site if one wasn’t already availleble, so our site becomes an https-site. See https:// downloads.deployctl.com for the result of the production environment.
Below we will go step by step through the
.gitlab-ci.yml-file for the deployctl project:
Defining the stages
Defining the variables for deployment
- CI_PROJECT_PATH_SLUG mandatory slug of PROJECT_PATH (name with namespace)
- DEPLOY_DOMAIN_APP : on which domain we’ll deploy the:
- DEPLOY_DOMAIN: where we deploy the production environment
- DEPLOY_CONFIG_HTTPS: configure https for a production environment
- DEPLOY_RELEASE_PATH: ‘[“output/”,”output/rpm/”,”output/dist/”]’
Building the project and distro
Both builds do a checkout from Gitlab project, and places the desired output in
- Build provides the scripts for setup,
.GIT_VERSION, for use by deployctl.
- build_dist provides the distro as a
Do the coverage testing
dependencies: : will not download artifacts from previous stages, and speeds up the job.
- the build provides us a file
coverage.urlwhich will turn into a link, with content e.g.
deployctl-coverage, 98.9%into a link on the Releases page:
- with name
- and hreflink of
- and a metric-value of
- Remark: metric is optional, if no
,in content, no metric will be shown.
- with name
packaging into an rpm
- GIT_STRATEGY: none => no git checkout
- so the
deployctl-*.tar.gzcomes from the distbuild,through the
GIT_STRATEGY: none on a shell runner is a bit tricky as previous build info can be present, so we delete and remake the
output-directory before copy the rpm.
On a branch commit, a review environment is created. this can be found on
The stop review allow the review to be deleted, manual or when branch is deleted.
Same as Review, but creates a master environment, meaning all commits to the master will have a master for review.
Besides that, a deployment is also made to a
bleeding edge repository
On creation of a new tag of the master branch, a staging environment is created.
Ready for review at
deployctl release creates and update the following:
Here we take the example of a tag-release
- creates the Release-tag page: http://downloads.deployctl.com/0-3-0
- creates the http://downloads.deployctl.com/0-3-0/release_json.js
- the data only for this tag.
- used to render the Release-tag Page.
- updates Releases page: http://downloads.deployctl.com
- updates the http://downloads.deployctl.com/release.json
- this file is the Releases database for this project.
- updates the http://downloads.deployctl.com/deployw_json.js
- allows without cross-domain settings to include in another web-project=> see Downloads
- is used to render the Releases-page
- configure https (let’s encrypt) if
DEPLOY_CONFIG_HTTPSis set True
And on a clean tag, a tag not containing the words
BETA,TEST,RC,PRC or ALPHA:
- creates a new http://downloads.deployctl.com/tag.svg
- updates http://downloads.deployctl.com/latest.tag
With DEPLOY_CONFIG_HTTPS set, it will make the production, and only production environment available on https, with a redirect of http to https.
To do that if no certificate is available for the domain-name, deployctl will have
acme.sh create a new letsencrypt certificate.
Also, on install of deployctl, a
crontab-job was created to automatically update the certificates.
Release info is only availleble for public projects, see Gitlab-issue #29566