| **.yml example**:
| ```
| trigger:
-| - master
+| - master # or the name of your main branch
| - feature/*
|
| steps:
| **.yml example**:
| ```
| trigger:
-| - master
+| - master # or the name of your main branch
| - feature/*
|
| steps:
| **.yml example**:
| ```
| trigger:
-| - master
+| - master # or the name of your main branch
| - feature/*
|
| steps:
| **.yml example**:
| ```
| trigger:
-| - master
+| - master # or the name of your main branch
| - feature/*
|
| steps:
|
| pipelines:
| branches:
-| '{master,develop}':
+| '{master,main,develop}':
| - step:
| name: SonarQube analysis
| caches:
|
| pipelines:
| branches:
-| '{master,develop}':
+| '{master,main,develop}':
| - step:
| name: SonarQube analysis
| caches:
| image: mcr.microsoft.com/dotnet/core/sdk:latest
| pipelines:
| branches:
-| '{master}':
+| '{master,main,develop}':
| - step:
| name: SonarQube analysis
| caches:
|
| pipelines:
| branches:
-| '{master,develop}':
+| '{master,main,develop}':
| - step:
| name: SonarQube analysis
| image: sonarsource/sonar-scanner-cli:latest
| allow_failure: true
| only:
| - merge_requests
-| - master
+| - master # or the name of your main branch
| - develop
| ```
| allow_failure: true
| only:
| - merge_requests
-| - master
+| - master # or the name of your main branch
| - develop
| ```
| allow_failure: true
| only:
| - merge_requests
-| - master
+| - master # or the name of your main branch
| - develop
| ```
|
No, you don't need to be connected to a SCM. However, SCM data still enhances the SonarQube experience (including issue auto-assignment and issue backdating), and you will be well prepared to take advantage of [Pull Request Analysis](/analysis/pull-request/)!
## What if I mark an Issue "Won't Fix" or "False-Positive" in a branch?
-It will be replicated as such when creating a pull request and merging the pull request into the master branch.
+It will be replicated as such when creating a pull request and merging the pull request into the main branch.
If you're using the **Reference Branch** [New Code](/project-administration/new-code-period/) definition, issues in the reference branch that come from a feature branch automatically inherit their attributes (including "Won't Fix" and "False Positive" resolutions) from the feature branch.
## Can I manually delete a branch?
### Settings and Quality Profiles on Branches
-Branch settings and Quality Profiles are the same as those set for the master branch, and by design, it's not possible to configure other values. The New Code Period is the only exception to this as it can be set on a branch-by-branch basis.
+Branch settings and Quality Profiles are the same as those set for the main branch, and by design, it's not possible to configure other values. The New Code Period is the only exception to this as it can be set on a branch-by-branch basis.
### New Code
You need to add a condition to your pipeline script to ensure only relevant branches are analyzed. For example, you wouldn't want to run analysis on feature branches that won't need analysis until they have pull requests .
-In the following example, analysis would be limited to branches named `master` or `release/*`.
+In the following example, analysis would be limited to branches named `main` or `release/*`.
```
-if [[ "$CI_BRANCH_NAME" == master ]] || [[ "$CI_BRANCH_NAME" == release/* ]]; then
+if [[ "$CI_BRANCH_NAME" == main ]] || [[ "$CI_BRANCH_NAME" == release/* ]]; then
./gradlew sonarqube
fi
```
### Issue Creation and Synchronization
-During the first analysis, issues (type, severity, status, assignee, change log, comments) are synchronized with the Main Branch. In each synchronized issue, a comment is added to the change log of the issue on the branch: "The issue has been copied from branch 'master' to branch 'yyy'".
+During the first analysis, issues (type, severity, status, assignee, change log, comments) are synchronized with the Main Branch. In each synchronized issue, a comment is added to the change log of the issue on the branch: "The issue has been copied from branch 'main' to branch 'yyy'".
At each subsequent analysis of the branch, any new issue in the Main Branch that comes from a pull request automatically inherits its attributes (type, severity, ...) from the pull request. A comment is added to the change log of the issue on the branch: "The issue has been merged from 'xxx' into 'yyy'"
`sonar.cluster.es.hosts`|Comma-delimited list of search hosts in the cluster. The list can contain either the host or the host and port but not both. The item format is `sonar.cluster.node.es.host` for host only or`sonar.cluster.node.es.host:sonar.cluster.node.es.port` for host and port.| |yes
`sonar.cluster.node.es.host`|Elasticsearch host of the current node used by Elasticsearch internal communication to form a cluster (TCP transport).|localhost|yes
`sonar.cluster.node.es.port`|Elasticsearch port of the current node used by Elasticsearch internal communication to form a cluster (TCP transport). Port must be accessible to all other search nodes|9002| yes
-`sonar.search.initialStateTimeout`|The timeout for the Elasticsearch nodes to elect a master node. The default value will be fine in most cases, but in a situation where startup is failing because of a timeout, this may need to be adjusted. The value must be set in the format: `{integer}{timeunit}`. Valid `{timeunit}` values are: `ms` (milliseconds); `s` (seconds); `m` (minutes); `h` (hours); `d` (days); `w` (weeks)|cluster: 120s; standalone: 30s|no
+`sonar.search.initialStateTimeout`|The timeout for the Elasticsearch nodes to elect a primary node. The default value will be fine in most cases, but in a situation where startup is failing because of a timeout, this may need to be adjusted. The value must be set in the format: `{integer}{timeunit}`. Valid `{timeunit}` values are: `ms` (milliseconds); `s` (seconds); `m` (minutes); `h` (hours); `d` (days); `w` (weeks)|cluster: 120s; standalone: 30s|no
### Elasticsearch authentication
Here is an example of configuration for pull requests when you are not on Travis CI and you need to configure your CI jobs:
```
-sonar.pullrequest.base=master
+sonar.pullrequest.base=main
sonar.pullrequest.branch=feature/my-new-feature
sonar.pullrequest.key=5
sonar.pullrequest.provider=GitHub
pipelines:
branches:
- '{master}':
+ '{master}': # or the name of your main branch
- step:
name: Download and install the build wrapper, build the project
script:
pipelines:
branches:
- '{master}':
+ '{master}': # or the name of your main branch
- step:
name: Download and install the build wrapper, build the project
script:
pipelines:
branches:
- '{master}':
+ '{master}': # or the name of your main branch
- step:
name: SonarQube analysis
caches:
pipelines:
branches:
- '{master}':
+ '{master}': # or the name of your main branch
- step:
name: SonarQube analysis
caches:
pipelines:
branches:
- '{master}':
+ '{master}': # or the name of your main branch
- step:
name: SonarQube analysis
caches:
pipelines:
branches:
- '{master}':
+ '{master}': # or the name of your main branch
- step:
name: SonarQube analysis
caches:
pipelines:
branches:
- '{master}':
+ '{master}': # or the name of your main branch
- step:
name: SonarQube analysis
caches:
pipelines:
branches:
- '{master}':
+ '{master}': # or the name of your main branch
- step:
name: SonarQube analysis
caches:
pipelines:
branches:
- '{master}':
+ '{master}': # or the name of your main branch
- step:
name: SonarQube analysis
script:
pipelines:
branches:
- '{master}':
+ '{master}': # or the name of your main branch
- step:
name: SonarQube analysis
script:
pipelines:
branches:
- '{master}':
+ '{master}': # or the name of your main branch
- step:
name: Download and install the build wrapper, build the project
script:
pipelines:
branches:
- '{master}':
+ '{master}': # or the name of your main branch
- step:
name: SonarQube analysis
caches:
pipelines:
branches:
- '{master}':
+ '{master}': # or the name of your main branch
- step:
name: SonarQube analysis
caches:
pipelines:
branches:
- '{master}':
+ '{master}': # or the name of your main branch
- step:
name: SonarQube analysis
caches:
pipelines:
branches:
- '{master}':
+ '{master}': # or the name of your main branch
- step:
name: SonarQube analysis
script:
on:
push:
branches:
- - master
+ - master # or the name of your main branch
${branchesEnabled ? ' pull_request:\n types: [opened, synchronize, reopened]' : ''}
jobs:
on:
push:
branches:
- - master
+ - master # or the name of your main branch
jobs:
on:
push:
branches:
- - master
+ - master # or the name of your main branch
pull_request:
types: [opened, synchronize, reopened]
on:
push:
branches:
- - master
+ - master # or the name of your main branch
pull_request:
types: [opened, synchronize, reopened]
} else {
const onlyBlock = branchesEnabled
? `- merge_requests
- - master
+ - master # or the name of your main branch
- develop`
: '- master # or the name of your main branch';
allow_failure: true
only:
- merge_requests
- - master
+ - master # or the name of your main branch
- develop
"
/>
allow_failure: true
only:
- merge_requests
- - master
+ - master # or the name of your main branch
- develop
"
/>
allow_failure: true
only:
- merge_requests
- - master
+ - master # or the name of your main branch
- develop
"
/>
allow_failure: true
only:
- merge_requests
- - master
+ - master # or the name of your main branch
- develop
"
/>
allow_failure: true
only:
- merge_requests
- - master
+ - master # or the name of your main branch
- develop
"
/>
allow_failure: true
only:
- merge_requests
- - master
+ - master # or the name of your main branch
- develop
"
/>
allow_failure: true
only:
- merge_requests
- - master
+ - master # or the name of your main branch
- develop
"
/>
allow_failure: true
only:
- merge_requests
- - master
+ - master # or the name of your main branch
- develop
"
/>
projects / sonarqube.git / commitdiff