| ~P1 | Urgent Priority | The current release + potentially immediate hotfix to GitLab.com (30 days) |
| ~P2 | High Priority | The next release (60 days) |
| ~P3 | Medium Priority | Within the next 3 releases (approx one quarter or 90 days) |
| ~P4 | Low Priority | Anything outside the next 3 releases (more than one quarter or 120 days) |
- ~P1
- ~P2
- ~P3
- ~P4
Please refer to the issue triage [priority label](https://about.gitlab.com/handbook/engineering/quality/issue-triage/#priority) section in our handbook to see how it's used.
### Severity labels
Severity labels help us clearly communicate the impact of a ~bug on users.
There can be multiple facets of the impact. The below is a guideline.
| ~S1 | Blocker | Unusable feature with no workaround, user is blocked | Impacts 50% or more of users | Outage, Significant impact on all of GitLab.com | | Above 9000ms to timing out |
| ~S2 | Critical Severity | Broken Feature, workaround too complex & unacceptable | Impacts between 25%-50% of users | Significant impact on large portions of GitLab.com | Degradation is guaranteed to occur in the near future | Between 2000ms and 9000ms |
| ~S3 | Major Severity | Broken feature with an acceptable workaround | Impacts up to 25% of users | Limited impact on important portions of GitLab.com | Degradation is likely to occur in the near future | Between 1000ms and 2000ms |
| ~S4 | Low Severity | Functionality inconvenience or cosmetic issue | Impacts less than 5% of users | Minor impact on GitLab.com | Degradation _may_ occur but it's not likely | Between 500ms and 1000ms |
If a bug seems to fall between two severity labels, assign it to the higher-severity label.
- Example(s) of ~S1
- Data corruption/loss.
- Security breach.
- Unable to create an issue or merge request.
- Unable to add a comment or thread to the issue or merge request.
- Example(s) of ~S2
- Cannot submit changes through the web IDE but the commandline works.
- A status widget on the merge request page is not working but information can be seen in the test pipeline page.
- Example(s) of ~S3
- Can create merge requests only from the Merge Requests list view, not from an Issue page.
- Status is not updated in real time and needs a page refresh.
- Example(s) of ~S4
- Label colors are incorrect.
- UI elements are not fully aligned.
We have the following severity labels:
- ~S1
- ~S2
- ~S3
- ~S4
Please refer to the issue triage [severity label](https://about.gitlab.com/handbook/engineering/quality/issue-triage/#severity) section in our handbook to see how it's used.
### Label for community contributors
...
...
@@ -505,8 +485,3 @@ to be involved in some capacity when work begins on the follow-up issue.
---
[Return to Contributing documentation](index.md)
[^1]:Our current response time standard is based on the TTFB P90 results of the
GitLab Performance Tool (GPT) being run against the 10k-user reference
environment. This run happens nightly and results are outputted to the
[wiki on the GPT project.](https://gitlab.com/gitlab-org/quality/performance/-/wikis/Benchmarks/Latest/10k)
# How to run Jenkins in development environment (on OSX) **(STARTER)**
This is a step by step guide on how to set up [Jenkins](https://jenkins.io/) on your local machine and connect to it from your GitLab instance. GitLab triggers webhooks on Jenkins, and Jenkins is connects to GitLab using the API. By running both applications on the same machine, we can make sure they are able to access each other.
## Install Jenkins
Install Jenkins and start the service using Homebrew.
```shell
brew install jenkins
brew services start jenkins
```
## Configure GitLab
GitLab does not allow requests to localhost or the local network by default. When running Jenkins on your local machine, you need to enable local access.
1. Log into your GitLab instance as an admin.
1. Go to **{admin}****Admin Area > Settings > Network**.
1. Expand `Outbound requests` and check the following checkboxes:
-**Allow requests to the local network from web hooks and services**
-**Allow requests to the local network from system hooks**
For more details about GitLab webhooks, see [Webhooks and insecure internal web services](../../security/webhooks.md).
Jenkins uses the GitLab API and needs an access token.
1. Log in to your GitLab instance.
1. Click on your profile picture, then click **Settings**.
1. Click **Access Tokens**.
1. Create a new Access Token with the **API** scope enabled. Note the value of the token.
## Configure Jenkins
Configure your GitLab API connection in Jenkins.
1. Make sure the GitLab plugin is installed on Jenkins. You can manage plugins in **Manage Jenkins > Manage Plugins**.
1. Set up the GitLab connection: Go to **Manage Jenkins > Configure System**, find the **GitLab** section and check the `Enable authentication for '/project' end-point` checkbox.
1. To add your credentials, click **Add** then choose **Jenkins Credential Provider**.
1. Choose **GitLab API token** as the type of token.
1. Paste your GitLab access token and click **Add**.
1. Choose your credentials from the dropdown menu.
1. Add your GitLab host URL. Normally `http://localhost:3000/`.
1. Click **Save Settings**.
For more details, see [GitLab documentation about Jenkins CI](../../integration/jenkins.md).
## Configure Jenkins Project
Set up the Jenkins project you are going to run your build on.
1. On your Jenkins instance, go to **New Item**.
1. Pick a name, choose **Pipeline** and click **ok**.
1. Choose your GitLab connection from the dropdown.
1. Check the **Build when a change is pushed to GitLab** checkbox.
1. Check the following checkboxes:
-**Accepted Merge Request Events**
-**Closed Merge Request Events**
1. Updating the status on GitLab must be done by a pipeline script. Add GitLab update steps, using the following as an example:
To activate the Jenkins service you must have a Starter subscription or higher.
1. Go to your project's page, then **Settings > Integrations > Jenkins CI**.
1. Check the `Active` checkbox and the triggers for `Push` and `Merge request`.
1. Fill in your Jenkins host, project name, username and password and click **Test settings and save changes**.
## Test your setup
Make a change in your repository and open an MR. In your Jenkins project it should have triggered a new build and on your MR, there should be a widget saying "Pipeline #NUMBER passed". It will also include a link to your Jenkins build.