gitlab-ci | DEPRECATED - Continuous integration server | Continous Integration library

This is the edit project API. The parameter controlling this is the ci_config_path.

As mentioned here:

Process started with Runner, even if you add nohup and & at the end, is marked with process group ID.
When the job is finished, the Runner is sending a kill signal to the whole process group.
So any process started directly from CI job will be terminated at job end.

Using a systenter code hereemd service (as in this same page) remains an option, if you control the target server.

Use only:variables: and set those variables in your schedules.

You can create a job than must be run manually

You can require that a job doesn’t run unless a user starts it.
This is called a manual job.

You might want to use a manual job for something like deploying to production.

To specify a job as manual, add when: manual to the job in the .gitlab-ci.yml file.

By default, manual jobs display as skipped when the pipeline starts.

The OP adds:

You can use a GitLab CI Job JWT token to login to Azure from within a CI/CD pipeline without needing to store secrets in a GitLab project. In order to do this, you will also need to configure OpenID Connect (OIDC) for ID federation between GitLab and an Azure service principal. This is recommended by Microsoft for authenticating to Azure from CI/CD services, among other use cases.

Note: Using OIDC as described below will only work if you are using gitlab.com or a publicly reachable GitLab instance. This is because Azure needs to connect to the token issuer for the keys to validate the token. If you are self-hosting GitLab and your instance is not publicly accessible, you can choose a different credential type for step 2.

First, you will need to register an Application in Azure. You can do this by following these instructions to register an application and create a service principal.

After doing this, make note of the values for Application (client) ID and Directory (tenant) ID (found in the application Overview pane). These values will be needed for step 3.

Once your app is registered, you can add federated credentials to the application's service principal. In the Azure portal, go to registered apps -> your application. In the sidebar, select Certificates & secrets. Under the Federated credentials tab, click the "Add credential" button

Use the following parameters for the credential configuration:

Federated credential sceanrio: Other issuer
Issuer: your gitlab URL e.g. https://gitlab.example.com
Subject Identifier: The value of the sub claim to match. For example, to allow jobs on the main branch of the contoso/myproject project to use this service principal, use project_path:contoso/myproject:ref_type:branch:ref:main
Name: Any descriptive name for the federated credental (e.g. contoso-myproject-main)
Description: Optional, a description for the federated credential.
Audience: your GitLab URL e.g. https://gitlab.example.com

After the federated credentials are created, you can leverage the CI_JOB_JWT_V2 token in your job to authenticate with Azure. In this example, we'll use the Azure CLI (az login).

You can define templates and then extend your jobs with them.

Documentation: https://docs.gitlab.com/ee/ci/yaml/#extends

Example:

After countless hours working on this, it seems that ultimately the issue was that our internal Web Application Firewall was blocking some part of the transfer of artefacts to the server, or the response back from it. With the WAF reconfigured not to block traffic from the machine running the GitLab Runner, the artefacts are successfully uploaded and the job succeeds.

This would have been significantly easier to diagnose if the logging from GitLab was better. As per my comment on this issue, it should be possible to see the content of the response from the GitLab server after uploading artefacts, even when the response code is 200.

What's strange - and made diagnosing the issue even harder - is that when I worked through the issue with the admin of our GitLab instance, digging through logs and running it in debug mode, the artefact upload process was uploading something successfully. We could see, for example, the GitLab Runner's log had been uploaded to the server. Clearly the WAF's blocking was selective and didn't block everything in both directions.

You do have three issues, I would say:

1. you should use an inline if expression of Jinja rather than a when
2. the backslash of the digit pattern have to be escaped to produce a valid in YAML: \\d
3. I guess the regex do not match what you think it does, to match between one and eight digit(s), the quantifier have to be used with a comma (,) to separate the minimum and the maximum repetition of the previous pattern, not a dash (-): \\d{1,8}

All together

This can be achieved even with a nicer and easier way to handle this.

You can use a special syntax for gitlab, as long as they are on the same instance. you can specify a project and optional ref and the file with this syntax like