gitlab-runner merge requestshttps://staging.gitlab.com/gitlab-org/gitlab-runner/-/merge_requests2017-09-11T16:54:35Zhttps://staging.gitlab.com/gitlab-org/gitlab-runner/-/merge_requests/485Update packages targets2017-09-11T16:54:35ZTomasz Maczukintomasz@gitlab.comUpdate packages targets## What does this MR do?
Updates the list of packages targets uploaded to packages.gitlab.com.
## Why was this MR needed?
## Are there points in the code the reviewer needs to double check?
## Does this MR meet the acceptance...## What does this MR do?
Updates the list of packages targets uploaded to packages.gitlab.com.
## Why was this MR needed?
## Are there points in the code the reviewer needs to double check?
## Does this MR meet the acceptance criteria?
- [ ] Documentation created/updated
- Tests
- [ ] Added for this feature/bug
- [ ] All builds are passing
- [ ] Branch has no merge conflicts with `master` (if you do - rebase it please)
## What are the relevant issue numbers?
Closes #1861, #2124v1.8Tomasz Maczukintomasz@gitlab.comTomasz Maczukintomasz@gitlab.comhttps://staging.gitlab.com/gitlab-org/gitlab-runner/-/merge_requests/458Add ubuntu/yakkety to packages generation list2017-01-25T23:30:31ZTomasz Maczukintomasz@gitlab.comAdd ubuntu/yakkety to packages generation list## What does this MR do?
Adds `ubuntu/yakkety` to the list of distributions for which we generate packages.
## Why was this MR needed?
To support installations on Ubuntu 16.10.
## Are there points in the code the reviewer needs to do...## What does this MR do?
Adds `ubuntu/yakkety` to the list of distributions for which we generate packages.
## Why was this MR needed?
To support installations on Ubuntu 16.10.
## Are there points in the code the reviewer needs to double check?
## Does this MR meet the acceptance criteria?
- [ ] Documentation created/updated
- Tests
- [ ] Added for this feature/bug
- [ ] All builds are passing
- [ ] Branch has no merge conflicts with `master` (if you do - rebase it please)
## What are the relevant issue numbers?v1.8Tomasz Maczukintomasz@gitlab.comTomasz Maczukintomasz@gitlab.comhttps://staging.gitlab.com/gitlab-org/gitlab-runner/-/merge_requests/403Fix link to CI secret variables2017-10-06T11:01:10ZAchilleas PipinellisFix link to CI secret variablesv1.8Achilleas PipinellisAchilleas Pipinellishttps://staging.gitlab.com/gitlab-org/gitlab-runner/-/merge_requests/393Make pull policies usage clear2017-10-06T11:01:09ZTomasz Maczukintomasz@gitlab.comMake pull policies usage clear## What does this MR do?
Describes the usage details and cases of `pull_policy` parameters: `always`, `if-not-present` and `never`. It also change code a little to remove unused policy check and log specific exceptions to make clear w...## What does this MR do?
Describes the usage details and cases of `pull_policy` parameters: `always`, `if-not-present` and `never`. It also change code a little to remove unused policy check and log specific exceptions to make clear what and why happened while determining the pulling policy.
## Why was this MR needed?
After adding support for private docker images in !386 and fixing inconsistence of behavior of `always` pull policy we introduced a change that breaks workflows based on previous bad implementation of `always` pull policy handling. This MR adds documentation and cosmetic changes in code to make clear which pull policy should be used in what cases.
## Are there points in the code the reviewer needs to double check?
## Does this MR meet the acceptance criteria?
- [x] Documentation created/updated
- Tests
- [x] Added for this feature/bug
- [ ] All builds are passing
- [ ] Branch has no merge conflicts with `master` (if you do - rebase it please)
## What are the relevant issue numbers?
Closes #1905v1.8Tomasz Maczukintomasz@gitlab.comTomasz Maczukintomasz@gitlab.comhttps://staging.gitlab.com/gitlab-org/gitlab-runner/-/merge_requests/392Rrefactor the private container registry docs2017-10-06T11:01:09ZAchilleas PipinellisRrefactor the private container registry docsv1.8Achilleas PipinellisAchilleas Pipinellishttps://staging.gitlab.com/gitlab-org/gitlab-runner/-/merge_requests/390Fix/unplug stalled endpoints2016-12-30T16:50:53ZTomasz Maczukintomasz@gitlab.comFix/unplug stalled endpoints> This is a general Merge Request template. Consider to choose a template
> from the list above if it will match your case more.
## What does this MR do?
Forces unlinking docker containers from docker networks while removing containers...> This is a general Merge Request template. Consider to choose a template
> from the list above if it will match your case more.
## What does this MR do?
Forces unlinking docker containers from docker networks while removing containers. This is to prevent docker API errors described in #1642.
## Why was this MR needed?
Successor of !337. Please look into !337 and #1642 for more details.
## Are there points in the code the reviewer needs to double check?
## Does this MR meet the acceptance criteria?
- [ ] Documentation created/updated
- Tests
- [x] Added for this feature/bug
- [x] All builds are passing
- [x] Branch has no merge conflicts with `master` (if you do - rebase it please)
## What are the relevant issue numbers?
Fixes #1642
/fyi @stanhuv1.8Tomasz Maczukintomasz@gitlab.comTomasz Maczukintomasz@gitlab.comhttps://staging.gitlab.com/gitlab-org/gitlab-runner/-/merge_requests/386Add support for using private docker registries2017-04-25T10:41:00ZTomasz Maczukintomasz@gitlab.comAdd support for using private docker registries> This is a general Merge Request template. Consider to choose a template
> from the list above if it will match your case more.
## What does this MR do?
Adds support for passing docker authorization config with environment variab...> This is a general Merge Request template. Consider to choose a template
> from the list above if it will match your case more.
## What does this MR do?
Adds support for passing docker authorization config with environment variable. This is a first step to add support for private registries (including private registry provided with GitLab CE/EE)
## Why was this MR needed?
## Are there points in the code the reviewer needs to double check?
## Does this MR meet the acceptance criteria?
- [x] Documentation created/updated
- Tests
- [x] Added for this feature/bug
- [ ] All builds are passing
- [x] Branch has no merge conflicts with `master` (if you do - rebase it please)
## What are the relevant issue numbers?
References #1434, #1828 and gitlab-org/gitlab-ce#22305v1.8Tomasz Maczukintomasz@gitlab.comTomasz Maczukintomasz@gitlab.comhttps://staging.gitlab.com/gitlab-org/gitlab-runner/-/merge_requests/385Add FAQ entry about handling the service logon failure on Windows2017-10-06T11:01:09ZTomasz Maczukintomasz@gitlab.comAdd FAQ entry about handling the service logon failure on Windows## What does this MR do?
Update FAQ and Windows installation docs with the description about how to handle the `The service did not start due to a logon failure` error when starting GitLab Runner as a service on Windows.
Closes #48.
/...## What does this MR do?
Update FAQ and Windows installation docs with the description about how to handle the `The service did not start due to a logon failure` error when starting GitLab Runner as a service on Windows.
Closes #48.
/cc @ayufanv1.8Kamil TrzcińśkiKamil Trzcińśkihttps://staging.gitlab.com/gitlab-org/gitlab-runner/-/merge_requests/382Fix broken documentation links2017-10-06T11:01:08ZAchilleas PipinellisFix broken documentation linksv1.8Achilleas PipinellisAchilleas Pipinellishttps://staging.gitlab.com/gitlab-org/gitlab-runner/-/merge_requests/381Add windows base integration tests configuration2016-12-06T19:51:11ZTomasz Maczukintomasz@gitlab.comAdd windows base integration tests configuration## What does this MR do?
## Why was this MR needed?
Please read #1829 for reference
## Are there points in the code the reviewer needs to double check?
## Does this MR meet the acceptance criteria?
- [ ] Documentation created/update...## What does this MR do?
## Why was this MR needed?
Please read #1829 for reference
## Are there points in the code the reviewer needs to double check?
## Does this MR meet the acceptance criteria?
- [ ] Documentation created/updated
- Tests
- [ ] Added for this feature/bug
- [ ] All builds are passing
- [ ] Branch has no merge conflicts with `master` (if you do - rebase it please)
## What are the relevant issue numbers?
References #1829v1.8Tomasz Maczukintomasz@gitlab.comTomasz Maczukintomasz@gitlab.comhttps://staging.gitlab.com/gitlab-org/gitlab-runner/-/merge_requests/380Fix docs links2017-10-06T11:01:08ZAchilleas PipinellisFix docs linksv1.8Achilleas PipinellisAchilleas Pipinellishttps://staging.gitlab.com/gitlab-org/gitlab-runner/-/merge_requests/379Revert "Merge branch 'bring-old-readme-back' into 'master'"2017-10-06T11:01:08ZAchilleas PipinellisRevert "Merge branch 'bring-old-readme-back' into 'master'"Now that https://gitlab.com/gitlab-com/gitlab-docs/merge_requests/11 is merged,
we can bring the new readme back.Now that https://gitlab.com/gitlab-com/gitlab-docs/merge_requests/11 is merged,
we can bring the new readme back.v1.8Achilleas PipinellisAchilleas Pipinellishttps://staging.gitlab.com/gitlab-org/gitlab-runner/-/merge_requests/376Bug Fix: use a regex to pull out the service and version in the splitServiceA...2017-06-05T15:12:55Zusername-removed-831160Bug Fix: use a regex to pull out the service and version in the splitServiceAndVersion methodThis merge request allows the use of multiple docker images (as a service) from a private docker registry where the docker registry is on a port other than 443.
Currently if you use a docker image from a private registry on a port ot...This merge request allows the use of multiple docker images (as a service) from a private docker registry where the docker registry is on a port other than 443.
Currently if you use a docker image from a private registry on a port other than 443 you can't have more than one service from that registry due to the way the service definition splits on the colon (:).
For example `registry.example.com:5000/ruby:2.9` becomes `registry.example.com` as a host entry to connect to. If you then have `registry.example.com:5000/mongo:2.6` this also becomes `registry.example.com` as an entry to connect to.
This ends up with:
```
registry.example.com -> ruby
registry.example.com -> mongo
```
Which of course doesn't work.
I have tried to take into account the different ways in which a private docker registry can be referenced in the regex and in the tests, but this could do with a review to see if my logic there covers everything.
I believe the docs cover the use of a private docker registry already and test have been updated.
(Note that the pipelines never pass the unit tests, but this is for the shell executor, on time outs, or when the test is killed by the runner.)v1.8https://staging.gitlab.com/gitlab-org/gitlab-runner/-/merge_requests/374Ensure that all builds are executed on tagged runners2016-11-08T16:46:16ZTomasz Maczukintomasz@gitlab.comEnsure that all builds are executed on tagged runners## What does this MR do?
Makes sure that all builds are executed on tagged runners.
## Why was this MR needed?
While working on integration tests (#1829) we'll need to add runners that will be used **only** for integration tests. This...## What does this MR do?
Makes sure that all builds are executed on tagged runners.
## Why was this MR needed?
While working on integration tests (#1829) we'll need to add runners that will be used **only** for integration tests. This MR updates the `.gitlab-ci.yml` file and explicitly describes which builds should be executed on which runners, to avoid problems after adding new runners.
## Are there points in the code the reviewer needs to double check?
## Does this MR meet the acceptance criteria?
- [ ] Documentation created/updated
- Tests
- [ ] Added for this feature/bug
- [ ] All builds are passing
- [ ] Branch has no merge conflicts with `master` (if you do - rebase it please)
## What are the relevant issue numbers?v1.8Tomasz Maczukintomasz@gitlab.comTomasz Maczukintomasz@gitlab.comhttps://staging.gitlab.com/gitlab-org/gitlab-runner/-/merge_requests/372Fix broken links in docs/index.md2017-10-06T11:01:07ZAchilleas PipinellisFix broken links in docs/index.mdv1.8Achilleas PipinellisAchilleas Pipinellishttps://staging.gitlab.com/gitlab-org/gitlab-runner/-/merge_requests/371Add a global index.md for docs2017-10-06T11:01:07ZAchilleas PipinellisAdd a global index.md for docsThis is needed in order to have GitLab Runner listed on docs.gitlab.com.
https://gitlab.com/gitlab-com/gitlab-docs/merge_requests/11
...This is needed in order to have GitLab Runner listed on docs.gitlab.com.
https://gitlab.com/gitlab-com/gitlab-docs/merge_requests/11
- The project's README.md points to the docs portal instead of the source files
- Every directory now has a readme or index file
Closes https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/issues/1798v1.8Achilleas PipinellisAchilleas Pipinellishttps://staging.gitlab.com/gitlab-org/gitlab-runner/-/merge_requests/370Fix "unit tests" random failures2016-11-15T18:03:39ZTomasz Maczukintomasz@gitlab.comFix "unit tests" random failures## What does this MR do?
Fixes randomly failing `unit tests` step in Runner's test suite.
## Why was this MR needed?
The `unit tests` step is randomly failing. Failures are caused mainly by accessing external resources and data ...## What does this MR do?
Fixes randomly failing `unit tests` step in Runner's test suite.
## Why was this MR needed?
The `unit tests` step is randomly failing. Failures are caused mainly by accessing external resources and data races during tests. Please fallow #1834 for reference.
## Are there points in the code the reviewer needs to double check?
Go chanels operations in `executors/docker/machine/provider_test.go `.
## Does this MR meet the acceptance criteria?
- [ ] Documentation created/updated
- Tests
- [x] Added for this feature/bug
- [ ] All builds are passing
- [ ] Branch has no merge conflicts with `master` (if you do - rebase it please)
## What are the relevant issue numbers?
Fixes #1834v1.8Tomasz Maczukintomasz@gitlab.comTomasz Maczukintomasz@gitlab.comhttps://staging.gitlab.com/gitlab-org/gitlab-runner/-/merge_requests/367Use correct constant for kubernetes ressource limits.2016-11-21T13:28:36Zusername-removed-810624Use correct constant for kubernetes ressource limits.## What does this MR do?
Fixes the Issue #1836. Use correct constants for limit names.
## Why was this MR needed?
Wrong constant for limit names were used.
## Are there points in the code the reviewer needs to double check?...## What does this MR do?
Fixes the Issue #1836. Use correct constants for limit names.
## Why was this MR needed?
Wrong constant for limit names were used.
## Are there points in the code the reviewer needs to double check?
## Does this MR meet the acceptance criteria?
- [x] Documentation created/updated
- Tests
- [x] Added for this feature/bug
- [x] All builds are passing
- [x] Branch has no merge conflicts with `master` (if you do - rebase it please)
## What are the relevant issue numbers?
Fixes #1836v1.8https://staging.gitlab.com/gitlab-org/gitlab-runner/-/merge_requests/366Handle received 'failed' build state while patching the trace2016-11-22T10:23:01ZTomasz Maczukintomasz@gitlab.comHandle received 'failed' build state while patching the trace## What does this MR do?
Fixes handling of builds that were marked as "failed" by GitLab. Please read gitlab-org/gitlab-ce#22087 for reference.
## Why was this MR needed?
After adding the trace patching feature we didn't handled...## What does this MR do?
Fixes handling of builds that were marked as "failed" by GitLab. Please read gitlab-org/gitlab-ce#22087 for reference.
## Why was this MR needed?
After adding the trace patching feature we didn't handled properly the situation when build was marked as "failed" on GitLab's side. This MR fixes this.
## Are there points in the code the reviewer needs to double check?
Construction of ` network/patch_response.go`.
## Does this MR meet the acceptance criteria?
- [ ] Documentation created/updated
- Tests
- [ ] Added for this feature/bug
- [ ] All builds are passing
- [ ] Branch has no merge conflicts with `master` (if you do - rebase it please)
## What are the relevant issue numbers?
Related to gitlab-org/gitlab-ce#22087v1.8Kamil TrzcińśkiKamil Trzcińśkihttps://staging.gitlab.com/gitlab-org/gitlab-runner/-/merge_requests/358Add initial Prometheus metrics server to runner manager2016-11-21T15:53:02ZJulius VolzAdd initial Prometheus metrics server to runner manager## What does this MR do?
This adds a new `metrics_server` config option. If set to a listening address, a Prometheus HTTP server is started with the following metrics:
- runner business logic metrics (currently only number of curre...## What does this MR do?
This adds a new `metrics_server` config option. If set to a listening address, a Prometheus HTTP server is started with the following metrics:
- runner business logic metrics (currently only number of currently running builds)
- build version information
- Go process metrics (GC stats, goroutines, memstats, ...)
- general process metrics (FDs, memory, cpu usage, ...)
A full example `/metrics` output can be found here: https://gist.github.com/juliusv/5a1972875e9d80654c63d222c480f87e
This depends on the data race fix in https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/merge_requests/352, so it's based ontop of that.
The approach to integrating the `metrics_server` configuration option was taken from https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/merge_requests/219.
## Why was this MR needed?
We need better insight into the entire CI system, and currently we have no white-box metrics.
## Are there points in the code the reviewer needs to double check?
### General metrics approach
There were multiple different ways of approaching this. The more "traditional" Prometheus style is to just register all metrics from anywhere in the codebase in the global default Prometheus registry (similar to how logging is often treated as a global concern without dependency-injecting a logger; and analogous to using `http.Handle(...)` to register a handler with the global HTTP mux).
However, from reading the rest of this codebase, it seemed to me like an approach with explicit dependencies and less global state would be preferred by the authors. So I'm instantiating a custom Prometheus metrics registry and registering the Go and process metrics collectors with it manually (those are included automatically in the default metrics registry). I also am using the `prometheus.Collector` interface to encapsulate the metrics of a type, instead of the simpler approach of just defining global metrics. For an example of the latter, see the example at the top of https://godoc.org/github.com/prometheus/client_golang/prometheus. Generally, this all leads to somewhat more code, but more explicit dependencies and encapsulation.
### Configuration reloading
Like in https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/merge_requests/219, the metrics HTTP server does not allow for reconfiguration. In Go, it's also not trivial to stop an already running HTTP server. So right now, only whatever is configured at process startup takes effect. Is that ok? Should it be a command-line flag instead?
Please let me know if this approach is generally going in the right direction. I know there's many other metrics we will want to add over time, but maybe let's start out simple?
## Does this MR meet the acceptance criteria?
- [x] Documentation created/updated
- Tests
- [ ] Added for this feature/bug
- [x] All builds are passing
- [x] Branch has no merge conflicts with `master` (if you do - rebase it please)
## What are the relevant issue numbers?
https://gitlab.com/gitlab-com/infrastructure/issues/543v1.8