'Releases are based on Git tags. We recommend tags that use semantic versioning, for example %{codeStart}v1.0%{codeEnd}, %{codeStart}v2.0-pre%{codeEnd}.',
'Releases are based on Git tags. We recommend tags that use semantic versioning, for example %{codeStart}v1.0.0%{codeEnd}, %{codeStart}v2.1.0-pre%{codeEnd}.',
raiseGitlab::Graphql::Errors::ResourceNotAvailable,'User is not authorized to register a runner for the specified resource!'ifinstructions.errors.include?('Gitlab::Access::AccessDeniedError')
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/5954) in [GitLab Starter](https://about.gitlab.com/pricing/) 11.1.
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/5954) in GitLab 11.1.
Updates a project issue board.
Updates a project issue board.
...
@@ -228,10 +228,10 @@ PUT /projects/:id/boards/:board_id
...
@@ -228,10 +228,10 @@ PUT /projects/:id/boards/:board_id
| `id` | integer/string | yes | The ID or [URL-encoded path of the project](README.md#namespaced-path-encoding) owned by the authenticated user |
| `id` | integer/string | yes | The ID or [URL-encoded path of the project](README.md#namespaced-path-encoding) owned by the authenticated user |
| `board_id` | integer | yes | The ID of a board |
| `board_id` | integer | yes | The ID of a board |
| `name` | string | no | The new name of the board |
| `name` | string | no | The new name of the board |
| `assignee_id`**(STARTER)** | integer | no | The assignee the board should be scoped to |
| `assignee_id`**(PREMIUM)** | integer | no | The assignee the board should be scoped to |
| `milestone_id`**(STARTER)** | integer | no | The milestone the board should be scoped to |
| `milestone_id`**(PREMIUM)** | integer | no | The milestone the board should be scoped to |
| `labels`**(STARTER)** | string | no | Comma-separated list of label names which the board should be scoped to |
| `labels`**(PREMIUM)** | string | no | Comma-separated list of label names which the board should be scoped to |
| `weight`**(STARTER)** | integer | no | The weight range from 0 to 9, to which the board should be scoped to |
| `weight`**(PREMIUM)** | integer | no | The weight range from 0 to 9, to which the board should be scoped to |
```shell
```shell
curl --request PUT --header"PRIVATE-TOKEN: <your_access_token>""https://gitlab.example.com/api/v4/projects/5/boards/1?name=new_name&milestone_id=43&assignee_id=1&labels=Doing&weight=4"
curl --request PUT --header"PRIVATE-TOKEN: <your_access_token>""https://gitlab.example.com/api/v4/projects/5/boards/1?name=new_name&milestone_id=43&assignee_id=1&labels=Doing&weight=4"
@@ -22,13 +22,13 @@ a black-box testing framework for the API and the UI.
...
@@ -22,13 +22,13 @@ a black-box testing framework for the API and the UI.
### Testing nightly builds
### Testing nightly builds
We run scheduled pipelines each night to test nightly builds created by Omnibus.
We run scheduled pipelines each night to test nightly builds created by Omnibus.
You can find these nightly pipelines at `https://gitlab.com/gitlab-org/quality/nightly/pipelines`
You can find these pipelines at <https://gitlab.com/gitlab-org/quality/nightly/pipelines>
(need Developer access permissions). Results are reported in the `#qa-nightly` Slack channel.
(need Developer access permissions). Results are reported in the `#qa-nightly` Slack channel.
### Testing staging
### Testing staging
We run scheduled pipelines each night to test staging.
We run scheduled pipelines each night to test staging.
You can find these nightly pipelines at `https://gitlab.com/gitlab-org/quality/staging/pipelines`
You can find these pipelines at <https://gitlab.com/gitlab-org/quality/staging/pipelines>
(need Developer access permissions). Results are reported in the `#qa-staging` Slack channel.
(need Developer access permissions). Results are reported in the `#qa-staging` Slack channel.
### Testing code in merge requests
### Testing code in merge requests
...
@@ -36,64 +36,63 @@ You can find these nightly pipelines at `https://gitlab.com/gitlab-org/quality/s
...
@@ -36,64 +36,63 @@ You can find these nightly pipelines at `https://gitlab.com/gitlab-org/quality/s
#### Using the `package-and-qa` job
#### Using the `package-and-qa` job
It is possible to run end-to-end tests for a merge request, eventually being run in
It is possible to run end-to-end tests for a merge request, eventually being run in
a pipeline in the [`gitlab-qa-mirror`](https://gitlab.com/gitlab-org/gitlab-qa-mirror/) project,
a pipeline in the [`gitlab-org/gitlab-qa-mirror`](https://gitlab.com/gitlab-org/gitlab-qa-mirror) project,
by triggering the `package-and-qa` manual action in the `test` stage (not
by triggering the `package-and-qa` manual action in the `qa` stage (not
available for forks).
available for forks).
**This runs end-to-end tests against a custom CE and EE (with an Ultimate license)
**This runs end-to-end tests against a custom EE (with an Ultimate license)
Omnibus package built from your merge request's changes.**
Docker image built from your merge request's changes.**
Manual action that starts end-to-end tests is also available in merge requests
Manual action that starts end-to-end tests is also available
in [Omnibus GitLab](https://gitlab.com/gitlab-org/omnibus-gitlab).
in [`gitlab-org/omnibus-gitlab` merge requests](https://docs.gitlab.com/omnibus/build/team_member_docs.html#i-have-an-mr-in-the-omnibus-gitlab-project-and-want-a-package-or-docker-image-to-test-it).
Below you can read more about how to use it and how does it work.
#### How does it work?
#### How does it work?
Currently, we are using _multi-project pipeline_-like approach to run QA
Currently, we are using _multi-project pipeline_-like approach to run end-to-end
pipelines.
pipelines.
```mermaid
```mermaid
graph LR
graph TB
A1 -.->|1. Triggers an omnibus-gitlab-mirror pipeline and wait for it to be done| A2
A1 -.->|once done, can be triggered| A2
B2[`Trigger-qa` stage<br>`Trigger:qa-test` job] -.->|2. Triggers a gitlab-qa-mirror pipeline and wait for it to be done| A3
A2 -.->|1. Triggers an `omnibus-gitlab-mirror` pipeline<br>and wait for it to be done| B1
B2[`Trigger-qa` stage<br>`Trigger:qa-test` job] -.->|2. Triggers a `gitlab-qa-mirror` pipeline<br>and wait for it to be done| C1
subgraph "gitlab-foss/gitlab pipeline"
A1[`test` stage<br>`package-and-qa` job]
subgraph "`gitlab-org/gitlab` pipeline"
A1[`build-images` stage<br>`build-qa-image` and `build-assets-image` jobs]
and polls for the resulting status. We call this a _status attribution_.
1. GitLab packages are being built in the [Omnibus GitLab Mirror](https://gitlab.com/gitlab-org/build/omnibus-gitlab-mirror)
pipeline. Packages are then pushed to its Container Registry.
1. When packages are ready, and available in the registry, a final step in the
1. In the [`gitlab-org/build/omnibus-gitlab-mirror` pipeline](https://gitlab.com/gitlab-org/build/omnibus-gitlab-mirror):
[Omnibus GitLab Mirror](https://gitlab.com/gitlab-org/build/omnibus-gitlab-mirror) pipeline, triggers a new
1. Docker image is being built and pushed to its Container Registry.
GitLab QA pipeline (those with access can view them at `https://gitlab.com/gitlab-org/gitlab-qa-mirror/pipelines`). It also waits for a resulting status.
1. Finally, the `Trigger:qa-test` job triggers a new end-to-end pipeline in
[`gitlab-org/gitlab-qa-mirror`](https://gitlab.com/gitlab-org/gitlab-qa-mirror/pipelines) and polls for the resulting status.
1.GitLab QA pulls images from the registry, spins-up containers and runs tests
1.In the [`gitlab-org/gitlab-qa-mirror` pipeline](https://gitlab.com/gitlab-org/gitlab-qa-mirror):
against a test environment that has been just orchestrated by the `gitlab-qa`
1. Container for the Docker image stored in the [`gitlab-org/build/omnibus-gitlab-mirror`](https://gitlab.com/gitlab-org/build/omnibus-gitlab-mirror) registry is spun-up.
tool.
1. End-to-end tests are run with the `gitlab-qa` executable, which spin up a container for the end-to-end image from the [`gitlab-org/gitlab`](https://gitlab.com/gitlab-org/gitlab) registry.
1. The result of the GitLab QA pipeline is being
1. The result of the [`gitlab-org/gitlab-qa-mirror` pipeline](https://gitlab.com/gitlab-org/gitlab-qa-mirror) is being
propagated upstream, through Omnibus, back to the GitLab merge request.
propagated upstream (through polling from upstream pipelines), through [`gitlab-org/build/omnibus-gitlab-mirror`](https://gitlab.com/gitlab-org/build/omnibus-gitlab-mirror), back to the [`gitlab-org/gitlab`](https://gitlab.com/gitlab-org/gitlab) merge request.
Please note, we plan to [add more specific information](https://gitlab.com/gitlab-org/quality/team-tasks/-/issues/156)
Please note, we plan to [add more specific information](https://gitlab.com/gitlab-org/quality/team-tasks/-/issues/156)
about the tests included in each job/scenario that runs in `gitlab-qa-mirror`.
about the tests included in each job/scenario that runs in `gitlab-org/gitlab-qa-mirror`.
To get a usage ping, or to troubleshoot caching issues on your GitLab instance, please follow [instructions to generate usage ping](../../administration/troubleshooting/gitlab_rails_cheat_sheet.md#generate-usage-ping).
This activity is to be done via a detached screen session on a remote server.
Before you begin these steps, make sure the key is added to the SSH agent locally
with the `ssh-add` command.
### Triggering
1. Connect to bastion with agent forwarding: `$ ssh -A lb-bastion.gprd.gitlab.com`
1. Create named screen: `$ screen -S <username>_usage_ping_<date>`
1. Connect to console host: `$ ssh $USER-rails@console-01-sv-gprd.c.gitlab-production.internal`
1. Run `SubmitUsagePingService.new.execute`
1. Detach from screen: `ctrl + a, ctrl + d`
1. Exit from bastion: `$ exit`
### Verification (After approx 30 hours)
1. Reconnect to bastion: `$ ssh -A lb-bastion.gprd.gitlab.com`
1. Find your screen session: `$ screen -ls`
1. Attach to your screen session: `$ screen -x 14226.mwawrzyniak_usage_ping_2021_01_22`
1. Check the last payload in `raw_usage_data` table: `RawUsageData.last.payload`
1. Check the when the payload was sent: `RawUsageData.last.sent_at`
and **Secret** values. Copy these values, as you need them to configure Jira.
1. Check **API** in the **Scopes** section, and clear any other checkboxes.
## Configure Jira for DVCS
1. Click **Save application**. GitLab displays the generated **Application ID**
and **Secret** values. Copy these values, which you use in Jira.
If you use Jira Cloud and GitLab.com, use the [GitLab for Jira app](connect-app.md)
unless you specifically need the DVCS Connector.
## Jira DVCS Connector setup
Configure this connection when you want to import all GitLab commits and branches,
If you're using GitLab.com and Jira Cloud, use the
for the groups you specify, into Jira. This import takes a few minutes and, after
[GitLab for Jira app](connect-app.md) unless you have a specific need for the DVCS Connector.
it completes, refreshes every 60 minutes:
1. Ensure you have completed the [GitLab configuration](#gitlab-account-configuration-for-dvcs).
1. Ensure you have completed the [GitLab configuration](#configure-a-gitlab-application-for-dvcs).
1.If you're using Jira Server, go to **Settings (gear) > Applications > DVCS accounts**.
1.Go to your DVCS account:
If you're using Jira Cloud, go to **Settings (gear) > Products > DVCS accounts**.
-*For Jira Server,* go to **Settings (gear) > Applications > DVCS accounts**.
1. Click **Link GitHub Enterprise account** to start creating a new integration.
-*For Jira Cloud,* go to **Settings (gear) > Products > DVCS accounts**.
(We're pretending to be GitHub in this integration, until there's additional platform support in Jira.)
1. To create a new integration, select the appropriate value for **Host**:
1. Complete the form:
-*For Jira versions 8.14 and later:* Select **GitLab** or
<!-- vale gitlab.Substitutions = NO -->
1. Select **GitHub Enterprise** for the **Host** field.
**GitLab Self-Hosted**.
<!-- vale gitlab.Substitutions = YES -->
1. In the **Team or User Account** field, enter either:
-*For Jira versions 8.13 and earlier:* Select **GitHub Enterprise**.
1. For **Team or User Account**, enter either:
- The relative path of a top-level GitLab group that you have access to.
- The relative path of a top-level GitLab group that you have access to.
- The relative path of your personal namespace.
- The relative path of your personal namespace.
![Creation of Jira DVCS integration](img/jira_dev_panel_jira_setup_2.png)
1. In the **Host URL** field, enter the URI appropriate for your version of GitLab,
replacing `<gitlab.example.com>` with your GitLab instance domain:
1. In the **Host URL** field, enter `https://<gitlab.example.com>/`,
-*For GitLab versions 11.3 and later,* use `https://<gitlab.example.com>/`.
replacing `<gitlab.example.com>` with your GitLab instance domain. For example, if you are using GitLab.com,
-*For GitLab versions 11.2 and earlier,* use
this would be `https://gitlab.com/`.
`https://<gitlab.example.com>/-/jira`.
NOTE:
If using a GitLab version earlier than 11.3 the **Host URL** value should be `https://<gitlab.example.com>/-/jira`
1. For the **Client ID** field, use the **Application ID** value from the previous section.
1. For the **Client Secret** field, use the **Secret** value from the previous section.
1. For **Client ID**, use the **Application ID** value from the previous section.
1. For **Client Secret**, use the **Secret** value from the previous section.
1. Ensure that the rest of the checkboxes are checked.
1. Ensure that the rest of the checkboxes are checked.
1. Select **Add** to complete and create the integration.
1. Click **Add** to complete and create the integration.
To connect additional GitLab projects from other GitLab top-level groups, or
personal namespaces, repeat the previous steps with additional Jira DVCS accounts.
Jira takes up to a few minutes to know about (import behind the scenes) all the commits and branches
for all the projects in the GitLab group you specified in the previous step. These are refreshed
every 60 minutes.
In the future, we plan on implementing real-time integration. If you need
After you configure the integration, read more about [how to test and use it](index.md#usage).
to refresh the data manually, you can do this from the `Applications -> DVCS
accounts` screen where you initially set up the integration:
![Refresh GitLab information in Jira](img/jira_dev_panel_manual_refresh.png)
## Refresh data imported to Jira
To connect additional GitLab projects from other GitLab top-level groups (or personal namespaces), repeat the previous
Jira imports the commits and branches every 60 minutes for your projects. You
steps with additional Jira DVCS accounts.
can refresh the data manually from the Jira interface:
Now that the integration is configured, read more about how to test and use it in [Usage](index.md#usage).
1. Sign in to your Jira instance as the user you configured the integration with.
1. Go to **Settings (gear) > Applications**.
1. Select **DVCS accounts**.
1. In the table, for the repository you want to refresh, in the **Last Activity**
column, select the icon:
![Refresh GitLab information in Jira](img/jira_dev_panel_manual_refresh.png)
## Troubleshooting your DVCS connection
## Troubleshooting your DVCS connection
...
@@ -100,39 +100,46 @@ Refer to the items in this section if you're having problems with your DVCS conn
...
@@ -100,39 +100,46 @@ Refer to the items in this section if you're having problems with your DVCS conn
### Jira cannot access GitLab server
### Jira cannot access GitLab server
If you complete the **Add New Account** form, authorize access, and you receive
this error, Jira and GitLab cannot connect. No other error messages
appear in any logs:
```plaintext
```plaintext
Error obtaining access token. Cannot access https://gitlab.example.com from Jira.
Error obtaining access token. Cannot access https://gitlab.example.com from Jira.
```
```
This error message is generated in Jira, after completing the **Add New Account**
### SSL and TLS problems
form and authorizing access. It indicates a connectivity issue from Jira to
GitLab. No other error messages appear in any logs.
If there was an issue with SSL/TLS, this error message is generated.
Problems with SSL and TLS can cause this error message:
```plaintext
Error obtaining access token. Cannot access https://gitlab.example.com from Jira.
```
- The [GitLab Jira integration](../../user/project/integrations/jira.md) requires GitLab to connect to Jira. Any
- The [GitLab Jira integration](../../user/project/integrations/jira.md) requires
TLS issues that arise from a private certificate authority or self-signed
GitLab to connect to Jira. Any TLS issues that arise from a private certificate
certificate [are resolved on the GitLab server](https://docs.gitlab.com/omnibus/settings/ssl.html#other-certificate-authorities),
authority or self-signed certificate are resolved
[on the GitLab server](https://docs.gitlab.com/omnibus/settings/ssl.html#other-certificate-authorities),
as GitLab is the TLS client.
as GitLab is the TLS client.
- The Jira Development panel integration requires Jira to connect to GitLab, which
- The Jira Development panel integration requires Jira to connect to GitLab, which
causes Jira to be the TLS client. If your GitLab server's certificate is not
causes Jira to be the TLS client. If your GitLab server's certificate is not
issued by a public certificate authority, the Java Truststore on Jira's server
issued by a public certificate authority, the Java Truststore on Jira's server
needs to have the appropriate certificate added to it (such as your organization's
must have the appropriate certificate (such as your organization's
root certificate).
root certificate) added to it .
Refer to Atlassian's documentation and Atlassian Support for assistance setting up Jira correctly:
Refer to Atlassian's documentation and Atlassian Support for assistance setting up Jira correctly:
-[Adding a certificate to the trust store](https://confluence.atlassian.com/kb/how-to-import-a-public-ssl-certificate-into-a-jvm-867025849.html).
-[Add a certificate](https://confluence.atlassian.com/kb/how-to-import-a-public-ssl-certificate-into-a-jvm-867025849.html)
- Simplest approach is to use [`keytool`](https://docs.oracle.com/javase/8/docs/technotes/tools/unix/keytool.html).
to the trust store.
- The simplest approach is [`keytool`](https://docs.oracle.com/javase/8/docs/technotes/tools/unix/keytool.html).
- Add additional roots to Java's default Truststore (`cacerts`) to allow Jira to
- Add additional roots to Java's default Truststore (`cacerts`) to allow Jira to
also trust public certificate authorities.
also trust public certificate authorities.
- If the integration stops working after upgrading Jira's Java runtime, this
- If the integration stops working after upgrading Jira's Java runtime, the
might be because the `cacerts` Truststore got replaced.
`cacerts` Truststore may have been replaced during the upgrade.
-[Troubleshooting connectivity up to and including TLS handshaking](https://confluence.atlassian.com/kb/unable-to-connect-to-ssl-services-due-to-pkix-path-building-failed-error-779355358.html),
-Troubleshooting connectivity [up to and including TLS handshaking](https://confluence.atlassian.com/kb/unable-to-connect-to-ssl-services-due-to-pkix-path-building-failed-error-779355358.html),
using the a java class called `SSLPoke`.
using the a java class called `SSLPoke`.
- Download the class from Atlassian's knowledge base to a directory on Jira's server, such as `/tmp`.
- Download the class from Atlassian's knowledge base to Jira's server, for example to `/tmp`.
- Use the same Java runtime as Jira.
- Use the same Java runtime as Jira.
- Pass all networking-related parameters that Jira is called with, such as proxy
- Pass all networking-related parameters that Jira is called with, such as proxy
settings or an alternative root Truststore (`-Djavax.net.ssl.trustStore`):
settings or an alternative root Truststore (`-Djavax.net.ssl.trustStore`):
...
@@ -154,38 +161,42 @@ The requested scope is invalid, unknown, or malformed.
...
@@ -154,38 +161,42 @@ The requested scope is invalid, unknown, or malformed.
Potential resolutions:
Potential resolutions:
- Verify the URL shown in the browser after being redirected from Jira in step 5 of [Jira DVCS Connector Setup](#jira-dvcs-connector-setup) includes `scope=api` in the query string.
1. Verify that the URL shown in the browser after being redirected from Jira in the
- If `scope=api` is missing from the URL, return to [GitLab account configuration](#gitlab-account-configuration-for-dvcs) and ensure the application you created in step 1 has the `api` box checked under scopes.
[Jira DVCS connector setup](#configure-jira-for-dvcs) includes `scope=api` in
the query string.
1. If `scope=api` is missing from the URL, edit the
If a user sees a 404 when they would normally expect access, and the problem is limited to a specific group, search the `auth.log` rails log for one or more of the following:
-`json.message`: `'Attempting to access IP restricted group'`
-`json.allowed`: `false`
In viewing the log entries, compare the `remote.ip` with the list of
[allowed IPs](#restrict-group-access-by-ip-address) for the group.
@@ -96,7 +96,9 @@ Please note that the certificate [fingerprint algorithm](../../../integration/sa
...
@@ -96,7 +96,9 @@ Please note that the certificate [fingerprint algorithm](../../../integration/sa
-[Improved](https://gitlab.com/gitlab-org/gitlab/-/issues/292811) in GitLab 13.8, with an updated timeout experience.
-[Improved](https://gitlab.com/gitlab-org/gitlab/-/issues/292811) in GitLab 13.8, with an updated timeout experience.
-[Improved](https://gitlab.com/gitlab-org/gitlab/-/issues/211962) in GitLab 13.8 with allowing group owners to not go through SSO.
-[Improved](https://gitlab.com/gitlab-org/gitlab/-/issues/211962) in GitLab 13.8 with allowing group owners to not go through SSO.
With this option enabled, users must go through your group's GitLab single sign-on URL. They may also be added via SCIM, if configured. Users can't be added manually, and may only access project/group resources via the UI by signing in through the SSO URL.
With this option enabled, users must go through your group's GitLab single sign-on URL if they wish to access group resources through the UI. Users can't be manually added as members.
SSO enforcement does not affect sign in or access to any resources outside of the group. Users can view which groups and projects they are a member of without SSO sign in.
However, users are not prompted to sign in through SSO on each visit. GitLab checks whether a user
However, users are not prompted to sign in through SSO on each visit. GitLab checks whether a user
has authenticated through SSO. If it's been more than 1 day since the last sign-in, GitLab
has authenticated through SSO. If it's been more than 1 day since the last sign-in, GitLab
msgid "Releases are based on Git tags and mark specific points in a project's development history. They can contain information about the type of changes and can also deliver binaries, like compiled versions of your software."
msgid "Releases are based on Git tags and mark specific points in a project's development history. They can contain information about the type of changes and can also deliver binaries, like compiled versions of your software."
msgstr ""
msgstr ""
msgid "Releases are based on Git tags. We recommend tags that use semantic versioning, for example %{codeStart}v1.0%{codeEnd}, %{codeStart}v2.0-pre%{codeEnd}."
msgid "Releases are based on Git tags. We recommend tags that use semantic versioning, for example %{codeStart}v1.0.0%{codeEnd}, %{codeStart}v2.1.0-pre%{codeEnd}."
msgstr ""
msgstr ""
msgid "Releases documentation"
msgid "Releases documentation"
...
@@ -27056,6 +27062,9 @@ msgstr ""
...
@@ -27056,6 +27062,9 @@ msgstr ""
msgid "SecurityApprovals|Requires approval for vulnerabilities of Critical, High, or Unknown severity. %{linkStart}Learn more.%{linkEnd}"
msgid "SecurityApprovals|Requires approval for vulnerabilities of Critical, High, or Unknown severity. %{linkStart}Learn more.%{linkEnd}"