Gitlab runner linux remove dir build

In !1319 (merged) we added back the old way of how we cache the build directory for Docker since it causes regressions like #4174 (closed). However, the old behavior is incorrect and we should remove this earlier then %13.0 becuase %13.0 is a little long (1 year from now as of the time of writing)

Change Impact and Benefits

Proposal

%11.11 Update the feature flag documentation to specify %12.3
In %11.11%12.0 release post announces that this is going to change.
In %12.0 update documentation educating users that they should never us build_dir for their own stuff, but should always be outside of that directory #4436 (closed)
In %13.0 remove the whole thing

Publish a blog post about the upcoming change, with a timeline and a simple way to recognize who is affected, and who is not.
Ask to schedule tweets about the blog post in the #twitter Slack channel.
Ask to reach out customers that may be affected by the change in the #customer-success and #sales Slack channels.
Mention the problems customers may report and how to address them in the #support_self-managed and #support_gitlab-com Slack channels

Источник

GitLab Runner commands

GitLab Runner contains a set of commands you use to register, manage, and run your builds.

You can check a recent list of commands by executing:

Append —help after a command to see its specific help page:

Using environment variables

Most of the commands support environment variables as a method to pass the configuration to the command.

You can see the name of the environment variable when invoking —help for a specific command. For example, you can see below the help message for the run command:

The output is similar to:

Running in debug mode

Debug mode is especially useful when looking for the cause of some undefined behavior or error.

To run a command in debug mode, prepend the command with —debug :

Super-user permission

Commands that access the configuration of GitLab Runner behave differently when executed as super-user ( root ). The file location depends on the user executing the command.

When you execute gitlab-runner commands, you see the mode it is running in:

You should use user-mode if you are sure this is the mode you want to work with. Otherwise, prefix your command with sudo :

In the case of Windows, you may need to run the command prompt as an administrator.

Configuration file

GitLab Runner configuration uses the TOML format.

You can find the file to be edited:

On *nix systems when GitLab Runner is executed as super-user ( root ): /etc/gitlab-runner/config.toml
On *nix systems when GitLab Runner is executed as non-root:

/.gitlab-runner/config.toml

On other systems: ./config.toml

Signals

You can use system signals to interact with GitLab Runner. The following commands support the following signals:

Command	Signal	Action
register	SIGINT	Cancel runner registration and delete if it was already registered.
run , exec , run-single	SIGINT, SIGTERM	Abort all running builds and exit as soon as possible. Use twice to exit now (forceful shutdown).
run , exec , run-single	SIGQUIT	Stop accepting a new builds. Exit as soon as currently running builds do finish (graceful shutdown).
run	SIGHUP	Force to reload configuration file.

For example, to force a reload of a runner’s configuration file, run:

If your operating system is configured to automatically restart the service if it fails (which is the default on some platforms) it may automatically restart the runner if it’s shut down by the signals above.

Commands overview

This is what you see if you run gitlab-runner without any arguments:

Below we explain what each command does in detail.

These commands support the following arguments:

Parameter	Default	Description
—config	See the configuration file section	Specify a custom configuration file to be used

gitlab-runner register

This command registers your runner in GitLab by using the GitLab Runners API.

The registered runner is added to the configuration file. You can use multiple configurations in a single installation of GitLab Runner. Executing gitlab-runner register adds a new configuration entry. It doesn’t remove the previous ones.

There are two options to register a runner:

interactive.
non-interactive.

Interactive registration

This command is usually used in interactive mode (default). You are asked multiple questions during a runner’s registration.

This question can be pre-filled by adding arguments when invoking the registration command:

Or by configuring the environment variable before the register command:

To check all possible arguments and environments execute:

Non-interactive registration

It’s possible to use registration in non-interactive / unattended mode.

You can specify the arguments when invoking the registration command:

Or by configuring the environment variable before the register command:

[[runners]] configuration template file

Introduced in GitLab Runner 12.2.

Additional options can be easily configured during runner registration using the configuration template file feature.

gitlab-runner list

This command lists all runners saved in the configuration file.

gitlab-runner verify

This command checks if the registered runners can connect to GitLab, but it doesn’t verify if the runners are being used by the GitLab Runner service. An example output is:

To remove the old runners that have been removed from GitLab, execute the following command.

gitlab-runner unregister

This command unregisters registered runners by using the GitLab Runners API.

It expects either:

A full URL and the runner’s token.
The runner’s name.

With the —all-runners option, it unregisters all the attached runners.

To unregister a specific runner, first get the runner’s details by executing gitlab-runner list :

Then use this information to unregister it, using one of the following commands.

By URL and token

By name

All runners

All service related commands accept these arguments:

Parameter	Default	Description
—service	gitlab-runner	Specify custom service name
—config	See the configuration file	Specify a custom configuration file to use

gitlab-runner install

This command installs GitLab Runner as a service. It accepts different sets of arguments depending on which system it’s run on.

When run on Windows or as super-user, it accepts the —user flag which allows you to drop privileges of builds run with the shell executor.

Parameter	Default	Description
—service	gitlab-runner	Specify service name to use
—config	See the configuration file	Specify a custom configuration file to use
—syslog	true (for non systemd systems)	Specify if the service should integrate with system logging service
—working-directory	the current directory	Specify the root directory where all data is stored when builds are run with the shell executor
—user	root	Specify the user that executes the builds
—password	none	Specify the password for the user that executes the builds

gitlab-runner uninstall

This command stops and uninstalls GitLab Runner from being run as an service.

gitlab-runner start

This command starts the GitLab Runner service.

gitlab-runner stop

This command stops the GitLab Runner service.

gitlab-runner restart

This command stops and then starts the GitLab Runner service.

gitlab-runner status

This command prints the status of the GitLab Runner service. The exit code is zero when the service is running and non-zero when the service is not running.

Multiple services

By specifying the —service flag, it is possible to have multiple GitLab Runner services installed, with multiple separate configurations.

This command allows to fetch and process builds from GitLab.

gitlab-runner run

This is main command that is executed when GitLab Runner is started as a service. It reads all defined runners from config.toml and tries to run all of them.

The command is executed and works until it receives a signal.

It accepts the following parameters.

Parameter	Default	Description
—config	See configuration-file	Specify a custom configuration file to be used
—working-directory	the current directory	Specify the root directory where all data is stored when builds run with the shell executor
—user	the current user	Specify the user that executes builds
—syslog	false	Send all logs to SysLog (Unix) or EventLog (Windows)
—listen-address	empty	Address ( : ) on which the Prometheus metrics HTTP server should be listening

gitlab-runner run-single

This is a supplementary command that can be used to run only a single build from a single GitLab instance. It doesn’t use any configuration file and requires to pass all options either as parameters or environment variables. The GitLab URL and Runner token need to be specified too.

You can see all possible configuration options by using the —help flag:

You can use the —max-builds option to control how many builds the runner executes before exiting. The default of 0 means that the runner has no build limit and jobs run forever.

You can also use the —wait-timeout option to control how long the runner waits for a job before exiting. The default of 0 means that the runner has no timeout and waits forever between jobs.

gitlab-runner exec

This command allows you to run builds locally, trying to replicate the CI environment as much as possible. It doesn’t need to connect to GitLab, instead it reads the local .gitlab-ci.yml and creates a new build environment in which all the build steps are executed.

This command is useful for fast checking and verifying .gitlab-ci.yml as well as debugging broken builds since everything is run locally.

When executing exec you need to specify the executor and the job name that is present in .gitlab-ci.yml . The command should be executed from the root directory of your Git repository that contains .gitlab-ci.yml .

gitlab-runner exec clones the current state of the local Git repository. Make sure you have committed any changes you want to test beforehand.

For example, the following command executes the job named tests locally using a shell executor:

To see a list of available executors, run:

To see a list of all available options for the shell executor, run:

If you want to use the docker executor with the exec command, use that in context of docker-machine shell or boot2docker shell . This is required to properly map your local directory to the directory inside the Docker container.

Limitations of gitlab-runner exec

With the current implementation of exec , some of the features of GitLab CI/CD may not work or may work partially.

We’re currently thinking about how to replace current exec implementation, to make it fully compatible with all features. Please track the issue for more details.

Compatibility table — features based on .gitlab-ci.yml

The following features are supported. If a feature is not listed in this table, it is not supported.

GitLab CI feature	Available with exec	Comments
image	yes	Extended configuration ( name , entrypoint ) are also supported.
services	yes	Extended configuration ( name , alias , entrypoint , command ) are also supported.
before_script	yes	Supports both global and job-level before_script .
after_script	partially	Global after_script is not supported. Only job-level after_script ; only commands are taken into consideration, when is hardcoded to always .
variables	yes	Supports default (partially), global and job-level variables; default variables are pre-set as can be seen in https://gitlab.com/gitlab-org/gitlab-runner/-/blob/c715666c059cc88a354d7cbcb5948b992d23f2a8/helpers/gitlab_ci_yaml_parser/parser.go#L149.
cache	partially	Regarding the specific configuration it may or may not work as expected.
YAML features	yes	Anchors ( & ), aliases ( * ), map merging ( ) are part of YAML specification and are handled by the parser.
pages	partially	Job’s script is executed if explicitly asked, but it doesn’t affect pages state, which is managed by GitLab.

Compatibility table — features based on variables

GitLab CI feature

Available with exec

Comments

GIT_STRATEGY

yes

GIT_CHECKOUT

yes

GIT_SUBMODULE_STRATEGY

yes

GIT_SUBMODULE_PATHS

yes

GET_SOURCES_ATTEMPTS

yes

ARTIFACT_DOWNLOAD_ATTEMPTS

Artifacts are not supported.

RESTORE_CACHE_ATTEMPTS

yes

GIT_DEPTH

yes

Compatibility table — other features

GitLab CI feature	Available with exec	Comments
Secret Variables	no
triggers	no
schedules	no
job timeout	no	Hardcoded to 1 hour.
[ci skip]	no Other requirements and limitations gitlab-runner exec docker can only be used when Docker is installed locally. This is needed because GitLab Runner is using host-bind volumes to access the Git sources. Internal commands GitLab Runner is distributed as a single binary and contains a few internal commands that are used during builds. gitlab-runner artifacts-downloader Download the artifacts archive from GitLab. gitlab-runner artifacts-uploader Upload the artifacts archive to GitLab. gitlab-runner cache-archiver Create a cache archive, store it locally or upload it to an external server. gitlab-runner cache-extractor Restore the cache archive from a locally or externally stored file. Troubleshooting Below are some common pitfalls. Access Denied when running the service-related commands Usually the service related commands require administrator privileges: On Unix (Linux, macOS, FreeBSD) systems, prefix gitlab-runner with sudo On Windows systems use the elevated command prompt. Run an Administrator command prompt. The simplest way is to write Command Prompt in the Windows search field, right click and select Run as administrator . You are asked to confirm that you want to execute the elevated command prompt. /usr/lib/gitlab-runner: No such file or directory The gitlab-runner executable was moved from /usr/lib/ to /usr/bin/ in GitLab 13.3. A symlink pointing /usr/lib/gitlab-runner to /usr/bin/gitlab-runner was added for backwards compatibility. In GitLab 14.0, the symlink was removed. To resolve the /usr/lib/gitlab-runner: No such file or directory error, you should do either of the following: Call gitlab-runner directly (assuming /usr/bin is in your $PATH ). Call /usr/bin/gitlab-runner . Источник Оцените статью Search for: Свежие записи Лучшие практики внедрения DevOps при разработке программного обеспечения Обзор Audacity для Mac и альтернатива Windows или Linux: Что лучше выбрать? Как в Windows 11 включить и выключить Безопасный режим? App data папка как почистить windows 10 Вам также может понравиться Windows или Linux: Что лучше выбрать? Есть много причин выбирать между Windows и Linux, но Файл владелец изменить linux Команда Chown в Linux Chown Command in Linux (File Установка шлюза по умолчанию linux Настройка сети вручную Содержание Краткое описание Чем разбить диск для linux ИТ База знаний Курс по Asterisk Полезно — Узнать IP — Правообладателям Политика конфиденциальности Контакты © 2024 Советы по настройке компьютера