debian-mirror-gitlab/doc/ci/enable_or_disable_ci.md

105 lines
3.4 KiB
Markdown
Raw Normal View History

2019-09-04 21:01:54 +05:30
---
type: howto
---
2018-03-17 18:26:18 +05:30
# How to enable or disable GitLab CI/CD
2019-09-04 21:01:54 +05:30
To effectively use GitLab CI/CD, you need:
- A valid [`.gitlab-ci.yml`](yaml/README.md) file present at the root directory
of your project.
- A [runner](runners/README.md) properly set up.
You can read our [quick start guide](quick_start/README.md) to get you started.
2018-03-17 18:26:18 +05:30
If you are using an external CI/CD server like Jenkins or Drone CI, it is advised
to disable GitLab CI/CD in order to not have any conflicts with the commits status
API.
2018-03-17 18:26:18 +05:30
GitLab CI/CD is exposed via the `/pipelines` and `/jobs` pages of a project.
Disabling GitLab CI/CD in a project does not delete any previous jobs.
In fact, the `/pipelines` and `/jobs` pages can still be accessed, although
2017-08-17 22:00:37 +05:30
it's hidden from the left sidebar menu.
2019-09-04 21:01:54 +05:30
GitLab CI/CD is enabled by default on new installations and can be disabled
either:
- Individually under each project's settings.
- Site-wide by modifying the settings in `gitlab.yml` and `gitlab.rb` for source
and Omnibus installations respectively.
2019-12-21 20:55:43 +05:30
NOTE: **Note:**
This only applies to pipelines run as part of GitLab CI/CD. This will not enable or disable
pipelines that are run from an [external integration](../user/project/integrations/project_services.md#services).
2018-03-17 18:26:18 +05:30
## Per-project user setting
2020-01-01 13:55:28 +05:30
To enable or disable GitLab CI/CD Pipelines in your project:
2019-12-21 20:55:43 +05:30
2020-01-01 13:55:28 +05:30
1. Navigate to **Settings > General > Visibility, project features, permissions**.
1. Expand the **Repository** section
2020-03-09 13:42:32 +05:30
1. Enable or disable the **Pipelines** toggle as required.
2020-01-01 13:55:28 +05:30
**Project visibility** will also affect pipeline visibility. If set to:
- **Private**: Only project members can access pipelines.
- **Internal** or **Public**: Pipelines can be set to either **Only Project Members**
2020-03-09 13:42:32 +05:30
or **Everyone With Access** via the dropdown box.
2019-12-21 20:55:43 +05:30
Press **Save changes** for the settings to take effect.
2018-03-17 18:26:18 +05:30
## Site-wide admin setting
2018-03-17 18:26:18 +05:30
You can disable GitLab CI/CD site-wide, by modifying the settings in `gitlab.yml`
2019-12-21 20:55:43 +05:30
for source installations, and `gitlab.rb` for Omnibus installations.
Two things to note:
2019-09-04 21:01:54 +05:30
- Disabling GitLab CI/CD, will affect only newly-created projects. Projects that
had it enabled prior to this modification, will work as before.
- Even if you disable GitLab CI/CD, users will still be able to enable it in the
project's settings.
For installations from source, open `gitlab.yml` with your editor and set
`builds` to `false`:
```yaml
## Default project features settings
default_projects_features:
issues: true
merge_requests: true
wiki: true
snippets: false
builds: false
```
2019-09-04 21:01:54 +05:30
Save the file and restart GitLab:
2020-03-09 13:42:32 +05:30
```shell
2019-09-04 21:01:54 +05:30
sudo service gitlab restart
```
For Omnibus installations, edit `/etc/gitlab/gitlab.rb` and add the line:
2019-09-04 21:01:54 +05:30
```ruby
2016-06-02 11:05:42 +05:30
gitlab_rails['gitlab_default_projects_features_builds'] = false
```
2019-09-04 21:01:54 +05:30
Save the file and reconfigure GitLab:
2020-03-09 13:42:32 +05:30
```shell
2019-09-04 21:01:54 +05:30
sudo gitlab-ctl reconfigure
```
<!-- ## Troubleshooting
Include any troubleshooting steps that you can foresee. If you know beforehand what issues
one might have when setting this up, or when something is changed, or on upgrading, it's
important to describe those, too. Think of things that may go wrong and include them here.
This is important to minimize requests for support, and to avoid doc comments with
questions that you know someone might ask.
Each scenario can be a third-level heading, e.g. `### Getting error message X`.
If you have none to add when creating a doc, leave this section in place
but commented out to help encourage others to add to it in the future. -->