deployctl now support deployment to a repository for rpm and deb packages with easy client install and multiple projects support.

  1. Setup a Repository
  2. Deploy to a Repository
  3. Use the package repository

Setup a Repository

To create a repository for deployment, we create a project, with a minimum of:

And Optional:

  • : a description of the repository to be displayed on the repository home page.


example: repo_helloworld

  - production

  DEPLOY_REPO_NAME: "repo_hello_world"
  DEPLOY_REPO_PATH: "output"

  stage: production
    name: production
    url: http://$DEPLOY_DOMAIN
    - deployctl repo_config

deployctl repo_config needs some variable to be setup:

  • CI_PROJECT_PATH_SLUG needs to be defined only if no custom domain in DEPLOY_DOMAIN is defined. Since gitlab 9.3, this is defined, but it can contain a _ making it a no go to use as part of a domain name since let’s encrypt does not accept _ as a valid domain name. see progress @ Gitlab issue #34643

  • DEPLOY_DOMAIN_APP is the domain where deployctl is running on , this is optional if a custom DEPLOY_DOMAIN is defined.

  • DEPLOY_DOMAIN what domain name is the repository reachable, need to have dns record for this domain to point to $DEPLOY_DOMAIN_APP.

  • DEPLOY_CONFIG_HTTPS: "True" if set deployctl will get a certificate and https is enabled for the repository.

  • DEPLOY_REPO_NAME the name of the repo, this name will be the name on the client install repository.

  • DEPLOY_REPO_PATH: basedir of repo where rpm/deb dir can be found in project, optional, defaults to repo/.


this is the actual configuration of the package repository and contains 3 sections:

  • projects: that are allowed to add packages to this repository.
  • environments: that are allowed to add packages to this repository.
  • repos: the repository definition.


list of projects that are allowed to add packages to this repository



will allow the gitlab projects access, this is the Access Control List.


lists the environments that are allowed to add packages to this repository, with wildcard support for review.


  • Only Production
  - production
  • All Environments can deploy
  - all
  • or : No environment defined
  - none
  • or : wildcards on review and multiples environments
  - review/*
  - master


the repository definition:

  - rpm:
    - mydist_release:
      - basearch: [ rpm_arch ]
    - el7:
      - x86_64: ['x86_64', 'athlon', 'i686', 'i586', 'i486', 'i386']
      - i386: ['i686', 'i586', 'i486', 'i386']
      - aarch64
      - armhfp:
        - armv7hl
  - deb:
    - dist:
      - release
    - debian:
      - wheezy
      - jessie
      - stretch

Remark 1:

basearch: [ rpm_arch ] : For RPM systems, the basearch is the distro architecture name ($basearch in the yum.repo), where as rpm_arch is the architecture of the binaries.

e.g.: armhfp: [armv7hl] : on centos the basearch for e.g. rasbery is armhfp where as the rpm architecture should be armv7hl, if not, rpm will not install as it only recognize armv7hl as compatible for the system.

Remark 2: No need to define noarch, a noarch rpm will go for all basearch as defined by distro.


this file is rendered into html and displayed on the repository landing page.

Furthermore some substitutions are foreseen :

Main purpose is to inform the users what the repository is for and how to install the repository.

deployctl generates 2 scripts for repository setup:

  • for debian based systems
  • for rpm based systems

Deploy to a Repository

In the project that needs to deploy packages to the repository, add the following to the .gilab-ci.yaml

  1. Define where the repository directory can be found:

    DEPLOY_REPO_PATH: base-dir where rpm and deb can be found.

  2. Define to which repository we need to deploy

    e.g. DEPLOY_REPO_URL: http(s)://myrepo.url

  3. Add deployctl add_repo to the deployment script.

    this can be combined with deployctl release in same environment.

  4. deployctl add_repo will automatically put the packages in the right place:

    1. for Debian Repository, wildcard matching is supported:

      • *.deb into /deb/ for all <dist/releases>

      • *.deb into /deb/<dist> for all <releases> in <dist>

      • *.deb into /deb/<dist>/<release> for specific <dist/release>

    2. for RPM:

      • have all *.rpm in /rpm

      • matching arch: multi-arch to the basearch RPM-TAG

      • distro matching according to 2 char-code in the release RPM-TAG

      distro exceptions:

      • stripped of .centos for el7 from release RPM-TAG

      • For OpenSUSE/SLES, distro RPM-TAG is used as distro

    3. packages that can not be matched, are displayed as skipped

  5. a quick example

example to build an rpm-package and deploy it to the repository.


# Define the stages
  - build
  - deploy

# define the rpm build
# *.rpm files in rpm/ as artifacts for deployment
  stage: build
    - mkdir -pv rpmbuild/{RPMS,SRPMS,BUILD,SOURCES,SPECS,tmp}
    - cp -v libgit2-0.26.0.tar.gz rpmbuild/SOURCES/
    - cp -v libgit2.spec rpmbuild/SPECS/
    - >
       --define "_topdir $(pwd)/rpmbuild"
       -ba rpmbuild/SPECS/libgit2.spec
    - mkdir -pv rpm
    - cp -v rpmbuild/RPMS/x86_64/* rpm/
      - rpm
    - centos7

# ******************************************************
# The deployment to the package repository
# ******************************************************
  stage: deploy
    # No git checkout, dependency on build with artifacts
    GIT_STRATEGY: none
    # url of the repository
    # Path where the rpm-directory can be found
    - deployctl repo_add
    # tag of the deployctl runner
  # repository allows only production environments
    name: production

Use the package repository

deployctl provides automatic setup of the repository:

Run on the client:

  • RPM/YUM: curl <repo_url>/ | sudo bash

  • Debian: curl <repo_url>/ | sudo bash

and install the newpackage with:

  • RPM/YUM: yum install <newpackage>

  • RPM/dnf: dnf install <newpackage>

  • Debian: apt-get install <newpackage>


checkout :