diff options
author | GitLab Bot <gitlab-bot@gitlab.com> | 2020-03-26 09:08:40 +0300 |
---|---|---|
committer | GitLab Bot <gitlab-bot@gitlab.com> | 2020-03-26 09:08:40 +0300 |
commit | 116d4e56e83a1f408afe710ce070e699ba206475 (patch) | |
tree | cc62d3820d9bfa199061edfdef3a2f4bda140507 /doc/development | |
parent | dddde902acfa6acfb11583c61faa67cc7c8d11b6 (diff) |
Add latest changes from gitlab-org/gitlab@master
Diffstat (limited to 'doc/development')
-rw-r--r-- | doc/development/README.md | 1 | ||||
-rw-r--r-- | doc/development/contributing/issue_workflow.md | 55 | ||||
-rw-r--r-- | doc/development/integrations/jenkins.md | 92 |
3 files changed, 108 insertions, 40 deletions
diff --git a/doc/development/README.md b/doc/development/README.md index bc5f50b0499..94b67ee0dfa 100644 --- a/doc/development/README.md +++ b/doc/development/README.md @@ -164,6 +164,7 @@ Complementary reads: - [Jira Connect app](integrations/jira_connect.md) - [Security Scanners](integrations/secure.md) - [Secure Partner Integration](integrations/secure_partner_integration.md) +- [How to run Jenkins in development environment](integrations/jenkins.md) ## Testing guides diff --git a/doc/development/contributing/issue_workflow.md b/doc/development/contributing/issue_workflow.md index 31d99813061..a4c55cdbd1b 100644 --- a/doc/development/contributing/issue_workflow.md +++ b/doc/development/contributing/issue_workflow.md @@ -273,45 +273,25 @@ or ~"Stretch". Any open issue for a previous milestone should be labeled ### Priority labels -Priority labels help us define the time a ~bug fix should be completed. Priority determines how quickly the defect turnaround time must be. -If there are multiple defects, the priority decides which defect has to be fixed immediately versus later. -This label documents the planned timeline & urgency which is used to measure against our target SLO on delivering ~bug fixes. +We have the following priority labels: -| Label | Meaning | Target SLO (applies only to ~bug and ~security defects) | -|-------|-----------------|----------------------------------------------------------------------------| -| ~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. - -| Label | Meaning | Functionality | Affected Users | GitLab.com Availability | Performance Degradation | API/Web Response time[^1] | -|-------|-------------------|-------------------------------------------------------|----------------------------------|----------------------------------------------------|-------------------------------------------------------|----------------------------| -| ~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) diff --git a/doc/development/integrations/jenkins.md b/doc/development/integrations/jenkins.md new file mode 100644 index 00000000000..44ee80b7b3f --- /dev/null +++ b/doc/development/integrations/jenkins.md @@ -0,0 +1,92 @@ +# 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: + +**Example Pipeline Script:** + +```groovy +pipeline { + agent any + + stages { + stage('gitlab') { + steps { + echo 'Notify GitLab' + updateGitlabCommitStatus name: 'build', state: 'pending' + updateGitlabCommitStatus name: 'build', state: 'success' + } + } + } +} +``` + +## Configure your GitLab project + +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. |