Gitlab Instance

In the course of producing a fully realized Gitlab hosted code repository and CI environment, a configurable number of Gitlab instances are spun up, and exposed to the docker-compose service network.

By default, each Gitlab instance is served on the address localhost:808${INSTANCE_NUMBER} and is configured with a network alias assigned at gitlab:300${INSTANCE_NUMBER} which will be relevant when configuring runners.

Additionally, each Gitlab instance spins up with a root admin user, and a number of preconfigured, contrived users, projects, etc. Most of that can be safely ignored for our purposes.

Each instance requires some degree of administration before it can be properly utilized within the system, which can be accomplished following a few easy steps.

First the root user is the default user within the context of the Gitlab instance. This root user account will need to be utilized to perform any of the tasks required of the system. In order to use this root account, a user must first log in, using the default credentials:

Username	Password
root	5iveL!fe

which you will then be prompted to change. Do not forget the password selected as the backup, as there is no convenient way to change it as this time.

Once this user is logged in to the Gitlab instance, they will have access to the full suite of admin capabilities.

Unfortunately, for security reasons, Jacamar, the executor, does not allow jobs to be dispatched from the root user of the Gitlab instance, so a new user must be created.

An additional caveat to this workflow is that the user on the Gitlab side, dispatching a job payload (i.e. CI job from Gitlab) must have a corresponding user to whom Jacamar can downscope the job execution to.

For your convenience, a user has already been correctly configured for this purpose in the runner-jacmamar host container. This user is named gitlab, so on the Gitlab instance, create a new user named gitlab (case does not matter). This can be done by logging out of the root user and following the procedures outlined on the Gitlab instance when ‘create a new user’ is selected, or by following the steps on the Admin panel. If done via the log in page, the user will not immediately have permissions to access the Gitlab instance. Log back into the root account, navigate to the admin user panel and allow the user access.

You will now be able to log in and kick off CI jobs to the shared runner as that user. To add users that are able to kick off jobs, simply add that user to both the Gitlab instance and the runner-jacamar host container. Instructions for adding the user to the runner container can be found _____ here.