Version information
This version is compatible with:
- Puppet Enterprise 2023.8.x, 2023.7.x, 2023.6.x, 2023.5.x, 2023.4.x, 2023.3.x, 2023.2.x, 2023.1.x, 2023.0.x, 2021.7.x, 2021.6.x, 2021.5.x, 2021.4.x, 2021.3.x, 2021.2.x, 2021.1.x, 2021.0.x, 2019.8.x, 2019.7.x, 2019.5.x, 2019.4.x, 2019.3.x, 2019.2.x, 2019.1.x, 2019.0.x, 2018.1.x, 2017.3.x, 2017.2.x, 2016.4.x
- Puppet >= 4.10.0 < 9.0.0
Start using this module
Add this module to your Puppetfile:
mod 'aursu-gitlabinstall', '1.12.2'
Learn more about managing modules with a PuppetfileDocumentation
gitlabinstall
Table of Contents
- Description
- Setup - The basics of getting started with gitlabinstall
- Usage - Configuration options and additional functionality
- Limitations - OS compatibility, etc.
- Development - Guide for contributing to the module
Description
This module main goal is to install GitLab and provide ability to intagrate it with externally managed Nginx, Postgres and Docker Registry.
Setup
What gitlabinstall affects OPTIONAL
gitlabinstall installs gitlab-ce Omnibus package from https://packages.gitlab.com/gitlab/gitlab-ce. Exact package version should be provided
Also it could manage Nginx setup (non-bundled) and Postgres setup (also non-bundled)
SSL certificates management is also included
Setup Requirements
It requires to use custom fork of Puppet Nginx module located on GitHub.
For .fixtures.yml
nginx:
repo: https://github.com/aursu/puppet-nginx.git
ref: tags/v3.0.1-rc0.2
and for Puppetfile:
mod 'nginx',
:git => 'https://github.com/aursu/puppet-nginx.git',
:tag => 'v3.0.1-rc0.2'
Also requires non-published on Puppet Forge module aursu::lsys
which is set
of different basic profiles
Puppetfile setup:
mod 'lsys',
:git => 'https://github.com/aursu/puppet-lsys.git',
:tag => 'v0.21.0'
Beginning with gitlabinstall
Main class for GitLab installation is gitlabinstall::gitlab
:
class { 'gitlabinstall':
external_url => 'https://gitlab.domain.tld',
}
class { 'gitlabinstall::gitlab':
database_password => 'secret',
gitlab_package_ensure => '13.3.5-ce.0.el7',
}
Usage
External container registry integration
Use it with registry installed on separate host and on the same host as PuppetDB:
class { 'gitlabinstall':
external_url => 'https://gitlab.domain.tld',
}
class { 'gitlabinstall::gitlab':
cert_identity => '*.domain.tld',
# DevCI has PuppetDB which listen on 8080, PuppetDB could be used
# externally but not GitLab Unicorn
gitlab_rails_port => 8008,
monitoring => false,
external_registry_service => true,
registry_host => 'registry.domain.tld',
registry_api_url => 'http://registry.domain.tld:5000',
gitlab_package_ensure => '12.10.14-ce.0.el7',
}
Use it with registry on the same host:
class { 'gitlabinstall':
external_url => 'https://gitlab.domain.tld',
}
class { 'gitlabinstall::gitlab':
cert_identity => '*.domain.tld',
external_registry_service => true,
registry_host => 'registry.domain.tld',
}
LDAP settings
Basic setup:
class { 'gitlabinstall':
external_url => 'https://gitlab.domain.tld',
ldap_enabled => true,
ldap_host => 'ldap.mydomain.com',
ldap_password => 'secret',
ldap_base => 'ou=people,dc=gitlab,dc=example',
}
class { 'gitlabinstall::gitlab':
cert_identity => '*.domain.tld',
external_registry_service => true,
registry_host => 'registry.domain.tld',
}
With more LDAP settings:
class { 'gitlabinstall':
external_url => 'https://gitlab.domain.tld',
}
class { 'gitlabinstall::ldap':
host => 'ldap.mydomain.com',
password => 'secret',
base => 'ou=people,dc=gitlab,dc=example',
bind_dn => 'CN=Gitlab,OU=Users,DC=domain,DC=com',
}
class { 'gitlabinstall::gitlab':
cert_identity => '*.domain.tld',
external_registry_service => true,
registry_host => 'registry.domain.tld',
ldap_enabled => true,
}
Reference
See REFERENCE.md
Limitations
Development
Release Notes/Contributors/Etc. Optional
Reference
Table of Contents
Classes
gitlabinstall
: GitLab installationgitlabinstall::external_registry
: External registry integration into GitLabgitlabinstall::gitlab
: GitLab installation managementgitlabinstall::ldap
: Setup LDAP settings for GitLab instancegitlabinstall::nginx
: A short summary of the purpose of this classgitlabinstall::params
: Basic module settingsgitlabinstall::postgres
: Install postgres database and pg_trgm extensiongitlabinstall::ssl
: A short summary of the purpose of this class
Resource types
registry_token
: Registry authentication JWT token
Classes
gitlabinstall
GitLab installation
Examples
include gitlabinstall
Parameters
The following parameters are available in the gitlabinstall
class.
gitlab_package_ensure
Data type: String
RPM package version. For example, 13.3.2-ce.0.el7 (see https://packages.gitlab.com/gitlab/gitlab-ce)
Default value: '13.0.10-ce.0.el7'
external_url
Data type: Stdlib::HTTPUrl
Configuring the external URL for GitLab see Configuring the external URL for GitLab
Default value: 'http://localhost'
database_password
Data type: Optional[String]
PostgreSQL database password
Default value: undef
manage_cert_data
Data type: Boolean
Whether provided certificate and key should be installed on server or not
Default value: true
cert_identity
Data type: Optional[String]
Certificate name to use in order to lookup certificate data in Puppet Hiera
Default value: undef
external_postgresql_service
Data type: Boolean
Using a non-packaged PostgreSQL database management server see Using a non-packaged PostgreSQL database management server
Default value: true
manage_postgresql_core
Data type: Boolean
Whether to manage PostgreSQL core or not (installation, initialization, service start)
Default value: true
non_bundled_web_server
Data type: Boolean
Whether to use bundled into GitLab Nginx service or not
Default value: true
manage_nginx_core
Data type: Boolean
Whether to manage core settings for Nginx or not (installation, nginx.conf setup, service setup)
Default value: true
external_registry_service
Data type: Boolean
Whether to integrate external Container registry into GitLab or not
Default value: false
registry_host
Data type: Optional[Stdlib::Fqdn]
Registry endpoint without the scheme, the address that gets shown to the end user.
Default value: undef
registry_port
Data type: Integer
Registry endpoint port, visible to the end user
Default value: 443
registry_api_url
Data type: Stdlib::HTTPUrl
Registry API URL Gitlab should connect to
Default value: 'http://localhost:5000'
ldap_enabled
Data type: Boolean
Whether to enable LDAP settings or not
Default value: false
ldap_base
Data type: Optional[String]
LDAP base where we can search for users.
Default value: undef
ldap_password
Data type: Optional[String]
The password of the LDAP bind user.
Default value: undef
ldap_host
Data type: Optional[String]
IP address or domain name of your LDAP server.
Default value: undef
database_host
Data type: Variant[Stdlib::Fqdn, Stdlib::IP::Address]
Default value: 'localhost'
monitoring_whitelist
Data type: Array[Stdlib::IP::Address]
Default value: []
gitlabinstall::external_registry
External registry integration into GitLab
Examples
include gitlabinstall::external_registry
Parameters
The following parameters are available in the gitlabinstall::external_registry
class.
registry_host
Data type: Stdlib::Fqdn
Registry endpoint without the scheme, the address that gets shown to the end user. it is gitlab_rails['registry_host'] setting in /etc/gitlab/gitlab.rb
Default value: $gitlabinstall::registry_host
registry_api_url
Data type: Stdlib::HTTPUrl
This is the Registry URL used internally that users do not need to interact with it is gitlab_rails['registry_api_url'] setting in /etc/gitlab/gitlab.rb
Default value: $gitlabinstall::registry_api_url
registry_port
Data type: Integer
Registry endpoint port, visible to the end user it is gitlab_rails['registry_port'] setting in /etc/gitlab/gitlab.rb
Default value: $gitlabinstall::registry_port
registry_internal_key
Data type: Optional[String]
Contents of the key that GitLab uses to sign the tokens. It is registry['internal_key'] setting in /etc/gitlab/gitlab.rb A certificate-key pair is required for GitLab and the external container registry to communicate securely. You will need to create a certificate-key pair, configuring the external container registry with the public certificate and configuring GitLab with the private key
Default value: undef
registry_key_path
Path to the key that matches the certificate on the Registry side.
It is gitlab_rails['registry_key_path'] setting in /etc/gitlab/gitlab.rb
Custom file for Omnibus GitLab to write the contents of
registry['internal_key'] to. The file specified at registry_key_path
gets
populated with the content specified by internal_key
, each time reconfigure
is executed. If no file is specified, Omnibus GitLab will default it to
/var/opt/gitlab/gitlab-rails/etc/gitlab-registry.key
and will populate it.
registry_internal_certificate
Data type: Optional[String]
Contents of the certificate that GitLab uses to sign the tokens. This
parameter allows to setup custom certificate into file system path
(registry_cert_path
) or export to Puppet DB. It will not influence on
GitLab configuration (there is no support to embedded registry configuration
in this moodule)
Default value: undef
registry_cert_path
Data type: Optional[Stdlib::Unixpath]
This is the path where registry_internal_certificate
contents will be
written to disk.
default certificate location is /var/opt/gitlab/registry/gitlab-registry.crt
Default value: undef
registry_cert_export
Data type: Boolean
Whether to write certificate content intoo local file system or export it to Puppet DB
Default value: true
token_username
Data type: String
Username to use for default JWT auth token (as subject field). This token
will be generated and stored into file /etc/docker/registry/token.json
and available through custom fact gitlab_auth_token
Default value: 'registry-bot'
token_expire_time
Data type: Optional[String]
Expiration time for default JWT token. Could be unix timestamp or string representation of a time (which could be parsed by ruby function Time.parse) Default expiration time is 3600 seconds after current time
Default value: undef
token_expire_threshold
Data type: Optional[Integer]
Threshold for expiration time in seconds. If expiration time is less then current time plus threshold than Puppet will generate new auth token. Default threshold is 600 seconds
Default value: undef
gitlabinstall::gitlab
GitLab installation management
Examples
include gitlabinstall::gitlab
Parameters
The following parameters are available in the gitlabinstall::gitlab
class.
gitlab_package_ensure
Data type: String
RPM package version. For example, 13.3.2-ce.0.el7 (see https://packages.gitlab.com/gitlab/gitlab-ce)
Default value: $gitlabinstall::gitlab_package_ensure
log_dir
Data type: String
Log directory to manage
Default value: '/var/log/gitlab'
external_postgresql_service
Data type: Boolean
Using a non-packaged PostgreSQL database management server see Using a non-packaged PostgreSQL database management server
Default value: $gitlabinstall::external_postgresql_service
packages_enabled
Data type: Boolean
Enabling the Packages feature see GitLab Package Registry administration
Default value: true
packages_storage_path
Data type: Optional[Stdlib::Unixpath]
Local storage path for packages for Omnibus GitLab installation
Default value: $gitlabinstall::params::packages_storage_path
ssl_cert
Data type: Optional[String]
Content of x509 certificate to use for GitLab TLS setup
Default value: undef
ssl_key
Data type: Optional[String]
Content of RSA private key to use for GitLab TLS setup
Default value: undef
repo_sslverify
Data type: Optional[Integer[0,1]]
Set sslverify
flag for Omnibus GitLab Yum repository
Default value: undef
monitoring_whitelist
Data type: Array[Stdlib::IP::Address]
GitLab provides liveness and readiness probes to indicate service health. To access monitoring resources, the requesting client IP needs to be included in a whitelist. See https://docs.gitlab.com/ee/administration/monitoring/ip_whitelist.html
Default value: $gitlabinstall::monitoring_whitelist
database_password
Data type: String[8]
Default value: $gitlabinstall::database_password
manage_postgresql_core
Data type: Boolean
Default value: $gitlabinstall::manage_postgresql_core
database_host
Data type: String
Default value: $gitlabinstall::database_host
database_port
Data type: Variant[Integer, Pattern[/^[0-9]+$/]]
Default value: $gitlabinstall::params::database_port
database_username
Data type: String
Default value: $gitlabinstall::params::database_username
database_name
Data type: String
Default value: $gitlabinstall::params::database_name
non_bundled_web_server
Data type: Boolean
Default value: $gitlabinstall::non_bundled_web_server
manage_nginx_core
Data type: Boolean
Default value: true
manage_cert_data
Data type: Boolean
Default value: true
cert_identity
Data type: Optional[String]
Default value: undef
gitlab_rails_host
Data type: String
Default value: 'localhost'
gitlab_rails_port
Data type: Integer
Default value: 8080
monitoring
Data type: Boolean
Default value: false
external_registry_service
Data type: Boolean
Default value: $gitlabinstall::external_registry_service
mnt_distro
Data type: Optional[Stdlib::Unixpath]
Default value: undef
mnt_distro_fstype
Data type: String
Default value: 'ext4'
mnt_data
Data type: Optional[Stdlib::Unixpath]
Default value: undef
mnt_data_fstype
Data type: String
Default value: 'ext4'
ldap_enabled
Data type: Boolean
Default value: $gitlabinstall::ldap_enabled
gitlabinstall::ldap
Setup LDAP settings for GitLab instance see https://docs.gitlab.com/ee/administration/auth/ldap/
Examples
include gitlabinstall::ldap
Parameters
The following parameters are available in the gitlabinstall::ldap
class.
base
Data type: String
Base where we can search for users.
Default value: $gitlabinstall::ldap_base
prevent_ldap_sign_in
Data type: Boolean
When using another system such as SAML for authentication it can be desirable to disable LDAP for authentication. In particular LDAP can be a useful technology for synchronizing group membership, while being a security risk for sign in due to the way passwords are handled. Additionally it can allow users to bypass 2FA policies.
Default value: false
active_directory
Data type: Boolean
This setting specifies if LDAP server is Active Directory LDAP server. For non-AD servers it skips the AD specific queries. If your LDAP server is not AD, set this to false.
Default value: false
allow_username_or_email_login
Data type: Boolean
If enabled, GitLab will ignore everything after the first @ in the LDAP
username submitted by the user on sign-in. If you are using uid:
userPrincipalName
on ActiveDirectory you need to disable this setting,
because the userPrincipalName contains an @.
Default value: false
bind_dn
Data type: Optional[String]
The full DN of the user you will bind with.
Default value: undef
block_auto_created_users
Data type: Boolean
To maintain tight control over the number of active users on your GitLab installation, enable this setting to keep new users blocked until they have been cleared by the admin.
Default value: true
group_base
Data type: Optional[String]
Base used to search for groups.
Default value: undef
host
Data type: Variant[Stdlib::Fqdn, Stdlib::IP::Address]
IP address or domain name of your LDAP server.
Default value: $gitlabinstall::ldap_host
label
Data type: String
A human-friendly name for your LDAP server. It will be displayed on your sign-in page.
Default value: 'LDAP'
encryption
Data type: Enum['simple_tls', 'start_tls', 'plain']
Encryption method. The method
key is deprecated in favor of encryption
.
The encryption
value simple_tls
corresponds to 'Simple TLS' in the LDAP
library. start_tls
corresponds to StartTLS, not to be confused with
regular TLS. Normally, if you specify simple_tls
it will be on port 636,
while start_tls
(StartTLS) would be on port 389. plain
also operates on
port 389. Removed values: tls
was replaced with start_tls
and ssl
was
replaced with simple_tls
.
Default value: 'simple_tls'
password
Data type: String
The password of the bind user.
Default value: $gitlabinstall::ldap_password
port
Data type: Integer
The port to connect with on your LDAP server. 389 or 636 (for SSL)
Default value: 636
uid
Data type: Enum['userPrincipalName', 'sAMAccountName', 'uid']
LDAP attribute for username. Should be the attribute, not the value that
maps to the uid
.
Default value: 'uid'
user_filter
Data type: Optional[String]
Filter LDAP users. Format: RFC 4515
Default value: undef
full_name
Data type: Optional[String]
LDAP attribute for user display name. If no full name could be found at the
attribute specified for name
, the full name is determined using the
attributes specified for first_name
and last_name
.
Default value: undef
first_name
Data type: Optional[String]
LDAP attribute for user first name.
Default value: undef
last_name
Data type: Optional[String]
LDAP attribute for user last name.
Default value: undef
email
Data type: Optional[String]
LDAP attribute for user email.
Default value: undef
gitlabinstall::nginx
A description of what this class does
Examples
include gitlabinstall::nginx
Parameters
The following parameters are available in the gitlabinstall::nginx
class.
manage_service
Data type: Boolean
Whether to manage Nginx core settings or not
Default value: $gitlabinstall::manage_nginx_core
global_proxy_settings
Data type: Boolean
Whether to enable global proxy cache settings or not. These settings will
reside in Nginx http context (therefore they are global). These settings
could be applied only if Nginx core is managed not here (so manage_service
is false)
Default value: true
manage_log_directory
Data type: Boolean
Whether to create own log directory for GitLab or not. This directory
could be managed only if Nginx core is managed not here (so manage_service
is false)
Default value: true
monitoring_whitelist
Data type: Array[Stdlib::IP::Address]
GitLab provides liveness and readiness probes to indicate service health. To access monitoring resources, the requesting client IP needs to be included in a whitelist. See https://docs.gitlab.com/ee/administration/monitoring/ip_whitelist.html
Default value: $gitlabinstall::monitoring_whitelist
daemon_user
Data type: String
Default value: $gitlabinstall::params::user
daemon_user_id
Data type: Integer
Default value: $gitlabinstall::params::user_id
daemon_group
Data type: String
Default value: $gitlabinstall::params::group
daemon_group_id
Data type: Integer
Default value: $gitlabinstall::params::group_id
nginx_user_home
Data type: String
Default value: $gitlabinstall::params::user_home
web_server_user_shell
Data type: String
Default value: $gitlabinstall::params::user_shell
ssl
Data type: Boolean
Default value: false
ssl_cert_path
Data type: Optional[String]
Default value: undef
ssl_key_path
Data type: Optional[String]
Default value: undef
manage_document_root
Data type: Boolean
Default value: false
gitlabinstall::params
Basic module settings
Examples
include gitlabinstall::params
gitlabinstall::postgres
Install postgres database and pg_trgm extension
Examples
include gitlabinstall::postgres
Parameters
The following parameters are available in the gitlabinstall::postgres
class.
database_password
Data type: String[8]
Default value: $gitlabinstall::database_password
manage_service
Data type: Boolean
Default value: $gitlabinstall::manage_postgresql_core
database_username
Data type: String
Default value: $gitlabinstall::params::database_username
database_name
Data type: String
Default value: $gitlabinstall::params::database_name
gitlabinstall::ssl
A description of what this class does
Examples
include gitlabinstall::ssl
Parameters
The following parameters are available in the gitlabinstall::ssl
class.
server_name
Data type: Stdlib::Fqdn
GitLab server name (must be part of external_url)
cert_identity
Data type: Optional[String]
Certificate name to use in order to lookup certificate data in Puppet Hiera
Hiera lookup keys are <cert_identity>_private
and <cert_identity>_certificate
where <cert_identity>
is normalized value following next rules:
'*' -> 'wildcard', '.' -> '', '-' -> '', "'" -> '' and ' ' -> ''
cert_identity must match either certificate Common Name or any of Subject alternate DNS name
Default value: $gitlabinstall::cert_identity
ssl_cert
Data type: Optional[String]
Content of x509 certificate to use for GitLab TLS setup
Default value: undef
ssl_key
Data type: Optional[String]
Content of RSA private key to use for GitLab TLS setup
Default value: undef
manage_cert_data
Data type: Boolean
Whether provided certificate and key should be installed on server or not
Default value: $gitlabinstall::manage_cert_data
Resource types
registry_token
Registry authentication JWT token
Properties
The following properties are available in the registry_token
type.
access
Token access levels
Default value: absent
audience
Auth service
Default value: container_registry
ensure
Valid values: present
, absent
Create or remove token.
Default value: present
expire_time
Token expiration time
issued_at
Time when token have been issued at
issuer
Token issuer
Default value: omnibus-gitlab-issuer
not_before
Time when token starts to be valid
subject
Token username
ttl
Valid values: %r{^([0-9]+h)?([1-5]?[0-9]m)?([1-5]?[0-9]s)?$}
, %r{^[0-9]+s?$}
Controls the expiry of the token
Default value: 24h0m0s
Parameters
The following parameters are available in the registry_token
type.
id
Token ID
name
namevar
Token Name
provider
The specific backend to use for this registry_token
resource. You will seldom need to specify this --- Puppet will
usually discover the appropriate provider for your platform.
target
Valid values: %r{^[a-z0-9.-]+$}
File inside /etc/docker/registry directory where token should be stored
Default value: token.json
threshold
Validity threshold
Default value: 600
Changelog
All notable changes to this project will be documented in this file.
Release 1.0.2
Features
Added repo_sslverify
parameter into class gitlabinstall::gitlab
in order
to override global settings for this flag
Bugfixes
Added dependency of registry default path on gitlab package
Known Issues
Release 1.1.0
Features
- added IP allowlist support see https://docs.gitlab.com/ee/administration/monitoring/ip_whitelist.html
- added Health Check support see https://docs.gitlab.com/ee/user/admin_area/monitoring/health_check.html
- added Relative URL support see https://docs.gitlab.com/omnibus/settings/configuration.html#configuring-a-relative-url-for-gitlab
Bugfixes
Known Issues
Release 1.1.1
Features
Bugfixes
- Added ability to setup Nginx logging directory for GitLab if Nginx core is not under module management
Known Issues
Release 1.1.2
Features
- Added ability to export certificate that GitLab uses to sign the tokens
Bugfixes
Known Issues
Release 1.1.3
Features
- Revised/reworked auth configuration
Bugfixes
Known Issues
Release 1.1.4
Features
- Added ability to separate GitLab hostname and server name
Bugfixes
Known Issues
Release 1.1.5
Features
- Return registry
internal_key
management back into gitlabinstall
Bugfixes
Known Issues
Release 1.2.0
Features
- Added ability to setup LDAP settings
Bugfixes
Known Issues
Release 1.2.1
Features
- Added additional LDAP settings
Bugfixes
Known Issues
Release 1.3.0
Features
- Added authentication tokens
- Separated settinngs for external registry
Bugfixes
Known Issues
Release 1.4.0
Features
- Added
access
andttl
properties into access token type
Bugfixes
Known Issues
Release 1.5.0
Features
- Added postgresql tools setup
- Added template for tokens' map
Bugfixes
- Corrected name parameter for access field (not to start from slash /)
- Updated token validation (threshold should be less than ttl) if expire time is too close
- Changed dependency type for service cleanup
- Updated module dependencies
Known Issues
Release 1.5.1
Features
Bugfixes
- Corrected nginx::resource::config resource
- Enable map directory management in case if token auth enabled
Known Issues
Release 1.6.0
Features
- Added SMTP settings
Bugfixes
Known Issues
Release 1.7.0
Features
Bugfixes
- set Gitlab['gitlab_workhorse']['listen_addr'] to avoid default socket location change to /var/opt/gitlab/gitlab-workhorse/sockets/socket
Known Issues
Release 1.7.1
Features
Bugfixes
- Added dockerinstall into gitlabinstall::external_registry to avoid dependency errors
Known Issues
Release 1.7.2
Features
Bugfixes
- Updated puppet/gitlab version depenndency
Known Issues
Release 1.7.3
Features
Bugfixes
- Added
restorecon
command for workhorse socket to fix error [crit] 26914#26914: *1 connect() to unix:/var/opt/gitlab/gitlab-workhorse/socket failed (13: Permission denied) while connecting to upstream - Added
gitlab-rake db:migrate
command to fix error described in https://forum.gitlab.com/t/upgrading-from-13-9-4-to-13-10-0-results-in-an-error-500/50685/2
Known Issues
Release 1.8.0
Features
- Added GitLab Runner docker service installation (no Runner registration)
Bugfixes
Known Issues
Release 1.8.1
Features
- Bugfix: decline empty array for runners service extra hosts
Bugfixes
Known Issues
Release 1.9.0
Features
- Added runner registration
Bugfixes
Known Issues
Release 1.9.1
Features
- Moved default SSL settings into parameters
Bugfixes
Known Issues
Release 1.9.2
Features
- Upgraded default GitLab version to latest one [14.0.4]
Bugfixes
Known Issues
Release 1.9.3
Features
- Upgraded default GitLab version to latest one [14.2.4]
- Added database_upgrade flag
Bugfixes
Known Issues
Release 1.9.4
Features
- Added backup functionality for GitLab via cron job
- Upgraded default GitLab version to latest one [14.4.1]
Bugfixes
Known Issues
Release 1.9.5
Features
- Added ability to setup custom artifact path
- Upgraded default GitLab version to latest one [14.10.0]
- PDK upgrade to version 2.3.0
Bugfixes
Known Issues
Release 1.9.6
Features
- Added ability to specify version for jwt gem because latest versions (> 2.4.0 ) depend on Ruby >= 2.5 that is not the case for Puppet 5.5
Bugfixes
Known Issues
Release 1.9.7
Features
- Added ability to setup different ID for LDAP server provider
Bugfixes
Known Issues
Release 1.9.8
Features
- Added Git data path into module parameters
- Upgraded default GitLab version to latest one [15.3.3]
Bugfixes
Known Issues
Release 1.9.9
Features
- Upgraded default GitLab version to latest one [15.10.2]
- Upgraded default GitLab runner version to latest one [15.10.1]
Bugfixes
Known Issues
Release 1.9.10
Features
Bugfixes
- Added auth_type => 'gitlab_or_ldap' into registry token data
Known Issues
Release 1.9.12
Features
- Upgraded default GitLab version to latest 15.x [15.11.13]
Bugfixes
Known Issues
Release 1.10.1
Features
- PDK upgrade to 3.0.0
Bugfixes
- Bugfix for load custom type 'runner_registration' by r10k
Known Issues
Release 1.11.0
Features
- Added debug logic into runner_registration provider
Bugfixes
Known Issues
Release 1.12.2
Features
- Added ability to use authentication_token
Bugfixes
Known Issues
Dependencies
- aursu/dockerinstall (>= 0.9.5 < 1.0.0)
- puppet/gitlab (>= 6.0.0 < 9.0.0)
- aursu/lsys (>= 0.5.4 < 1.0.0)
- aursu/nginx (>= 2.0.0 < 5.0.0)
- puppetlabs/postgresql (>= 6.6.0 < 10.0.0)
- aursu/puppet (>= 0.1.5 < 1.0.0)
- puppet/selinux (>= 3.0.0 < 5.0.0)
- puppetlabs/stdlib (>= 4.1.0 < 10.0.0)
- aursu/tlsinfo (>= 0.3.5 < 1.0.0)