New answers tagged

0

Probably this https://gitlab.com/gitlab-org/cluster-integration/auto-deploy-image/-/blob/master/src/bin/auto-deploy .....................................................................


0

https://docs.gitlab.com/ee/topics/autodevops/quick_start_guide.html#install-ingress Go back to the cluster page on GitLab, and go to the Details tab. Add your Base domain. For this guide, use the domain .nip.io. Click Save changes. I think this option only showed up AFTER I installed the ingress.


0

As you suggested, having a build artifact to save the current commit SHA for the build would be ideal. Subsequent runs of the same workflow can download the artifact using the dawidd6/action-download-artifact action, which allows downloading artifacts generated from another workflow run. Snippet for uploading artifact: - name: Upload artifacts uses: ...


0

A gitlab runner is a process that f.e. tests, compiles your project, pushes the artefact to you artefact store etc. A Gitlab runner can be tagged inside Gitlab or via config.toml - so - you can assign runners via tags to Gitlab projects (shared). Gitlab runner are not designed to run an application 24x7. So - you assign a project to a runner (or a tag or all)...


0

Answering my own question here. "Multi project pipeline" is not necessary here. You simply have a single project and mark jobs with different "tags". You can then register runners for these different tags, on different machines. (Artifacts are transferred from one job to the next the same, regardless if the runners are run on the same ...


1

Yes, you can use the rules syntax. You can use this in combination with regex for commit message, ci_pipeline_source or any other available CI variables. job1: script: - do something on schedule only rules: - if: '"$CI_PIPELINE_SOURCE" == "schedule"' when: always job2: script: - runs on Merge request pipeline ...


0

I guess you can do it via rules keyword. It has multiple condition with environment variables or branch name or schedules. If you add detail about you want to do, i try to Gitlab CI Rules


0

It was a simple mistake I made when I register gitlab-runner. I just used gitlab-runner register [options] But when I register it with sudo, it was working properly. sudo gitlab-runner register [option] Runner is running in Ubuntu-18.04 server.


0

My solution to this problem was two fold. First: As mentioned in the question, I was able to reduce the amount of concurrent Gitlab Instance runners to one, to avoid the usage of too many resource which was causing the shared runner freeze. To do this i moved all my integration tests into a single job. This didn't increase the time of the tests significantly ...


2

This is likely because your requests were dropped before they landed on the GitLab host. Check your firewalls and other security rules after assured that the 1234 port is open


1

I needed to change the distribution type. Thanks!


Top 50 recent answers are included