mirror of
https://gitlab.com/gitlab-org/gitlab-foss.git
synced 2025-08-15 21:39:00 +00:00
Add latest changes from gitlab-org/gitlab@master
This commit is contained in:
GitLab Bot
@ -50,6 +50,11 @@ export default {
|
||||
id: convertToGraphQLId(TYPENAME_COMMIT_STATUS, this.jobId),
|
||||
};
|
||||
},
|
||||
skip() {
|
||||
// variables list always contains one empty variable
|
||||
// skip refetch if form already has non-empty variables
|
||||
return this.variables.length > 1;
|
||||
},
|
||||
fetchPolicy: fetchPolicies.CACHE_AND_NETWORK,
|
||||
update(data) {
|
||||
const jobVariables = cloneDeep(data?.project?.job?.manualVariables?.nodes);
|
||||
|
||||
@ -7,7 +7,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
|
||||
# DevOps Reports **(FREE SELF)**
|
||||
|
||||
DevOps Reports give you an overview of your entire instance's adoption of
|
||||
[Concurrent DevOps](https://about.gitlab.com/topics/concurrent-devops/)
|
||||
[DevOps](https://about.gitlab.com/topics/devops/)
|
||||
from planning to monitoring.
|
||||
|
||||
To see DevOps Reports:
|
||||
|
||||
@ -980,7 +980,8 @@ Guidance for each individual UI element is in [the word list](word_list.md).
|
||||
|
||||
### How to write navigation task steps
|
||||
|
||||
To be consistent, use these templates when you write navigation steps in a task topic.
|
||||
To be consistent, use these examples to write navigation steps in a task topic.
|
||||
Although alternative steps might exist, use these steps instead.
|
||||
|
||||
To open project settings:
|
||||
|
||||
|
||||
@ -8,8 +8,10 @@ info: For assistance with this Style Guide page, see https://handbook.gitlab.com
|
||||
|
||||
Troubleshooting topics should be the final topics on a page.
|
||||
|
||||
If a page has more than five troubleshooting topics, put the content on a separate page that has troubleshooting information exclusively. Name the page `Troubleshooting <feature>`
|
||||
and in the left nav, use the word `Troubleshooting` only.
|
||||
If a page has five or more troubleshooting topics, put those topics on a separate page.
|
||||
|
||||
- Name the page `Troubleshooting <feature>`.
|
||||
- In the left nav, use the word `Troubleshooting` only.
|
||||
|
||||
## What type of troubleshooting information to include
|
||||
|
||||
|
||||
@ -239,7 +239,7 @@ Success also includes the case when vulnerabilities are found.
|
||||
|
||||
When a CI job fails, security report results are not ingested by GitLab, even if the job
|
||||
[allows failure](../../ci/yaml/index.md#allow_failure). However, the report artifacts are still uploaded to GitLab and available
|
||||
for [download in the pipeline security tab](../../user/application_security/vulnerability_report/pipeline.md#download-security-scan-outputs).
|
||||
for [download in the pipeline security tab](../../user/application_security/vulnerability_report/pipeline.md#downloading-security-scan-results).
|
||||
|
||||
### Logging
|
||||
|
||||
|
||||
@ -6,18 +6,18 @@ info: To determine the technical writer assigned to the Stage/Group associated w
|
||||
|
||||
# Jira **(FREE ALL)**
|
||||
|
||||
If your organization uses [Jira](https://www.atlassian.com/software/jira),
|
||||
you can [migrate your issues from Jira to GitLab](../../user/project/import/jira.md).
|
||||
You can [import your Jira issues to GitLab](../../user/project/import/jira.md).
|
||||
If you want to continue to use Jira, you can integrate Jira with GitLab instead.
|
||||
|
||||
## Jira integrations
|
||||
|
||||
GitLab offers two types of Jira integrations. You can use one or both integrations
|
||||
[depending on the capabilities you need](#jira-integration-capabilities).
|
||||
GitLab offers two Jira integrations. You can use one or both integrations
|
||||
[depending on the features you need](#feature-availability).
|
||||
|
||||
### Jira issue integration
|
||||
|
||||
You can use the [Jira issue integration](configure.md) developed by GitLab with Jira Cloud, Jira Data Center, or Jira Server. With this integration, you can:
|
||||
You can use the [Jira issue integration](configure.md) developed by GitLab with
|
||||
Jira Cloud, Jira Data Center, or Jira Server. With this integration, you can:
|
||||
|
||||
- View and search Jira issues directly in GitLab.
|
||||
- Refer to Jira issues by ID in GitLab commits and merge requests.
|
||||
@ -25,38 +25,40 @@ You can use the [Jira issue integration](configure.md) developed by GitLab with
|
||||
|
||||
### Jira development panel
|
||||
|
||||
You can use the [Jira development panel](development_panel.md) to [view GitLab activity for an issue](https://support.atlassian.com/jira-software-cloud/docs/view-development-information-for-an-issue/)
|
||||
You can use the [Jira development panel](development_panel.md) to
|
||||
[view GitLab activity for an issue](https://support.atlassian.com/jira-software-cloud/docs/view-development-information-for-an-issue/)
|
||||
including related branches, commits, and merge requests. To configure the Jira development panel:
|
||||
|
||||
- **For Jira Cloud**, use the [GitLab for Jira Cloud app](connect-app.md) developed and maintained by GitLab.
|
||||
- **For Jira Data Center or Jira Server**, use the [Jira DVCS connector](dvcs/index.md) developed and maintained by Atlassian.
|
||||
|
||||
## Jira integration capabilities
|
||||
## Feature availability
|
||||
|
||||
This table shows the capabilities available with the Jira issue integration and the Jira development panel:
|
||||
This table shows the features available with the Jira issue integration and the Jira development panel:
|
||||
|
||||
| Capability | Jira issue integration | Jira development panel |
|
||||
| Feature | Jira issue integration | Jira development panel |
|
||||
|-|-|-|
|
||||
| Mention a Jira issue ID in a GitLab commit or merge request, and a link to the Jira issue is created | **{check-circle}** Yes | **{dotted-circle}** No |
|
||||
| Mention a Jira issue ID in GitLab, and the Jira issue shows the GitLab issue or merge request | **{check-circle}** Yes, a Jira comment with the GitLab issue or merge request title links to GitLab. The first mention is also added to the Jira issue under **Web links** | **{check-circle}** Yes, in the issue's [development panel](https://support.atlassian.com/jira-software-cloud/docs/view-development-information-for-an-issue/) |
|
||||
| Mention a Jira issue ID in a GitLab commit message, and the Jira issue shows the commit message | **{check-circle}** Yes, the entire commit message is displayed in the Jira issue as a comment and under **Web links**. Each message links back to the commit in GitLab | **{check-circle}** Yes, in the issue's development panel and optionally with a custom comment on the Jira issue by using [Jira Smart Commits](https://confluence.atlassian.com/fisheye/using-smart-commits-960155400.html) |
|
||||
| Mention a Jira issue ID in a GitLab branch name, and the Jira issue shows the branch name | **{dotted-circle}** No | **{check-circle}** Yes, in the issue's development panel |
|
||||
| Add time tracking to a Jira issue | **{dotted-circle}** No | **{check-circle}** Yes, time can be specified by using Jira Smart Commits |
|
||||
| Use a Git commit or merge request to transition or close a Jira issue |**{check-circle}** Yes, only a single transition type. Typically configured to close the issue by setting it to **Done** | **{check-circle}** Yes, transition to any state by using Jira Smart Commits |
|
||||
| [View a list of Jira issues](issues.md#view-jira-issues) | **{check-circle}** Yes | **{dotted-circle}** No |
|
||||
| [Create a Jira issue for a vulnerability](configure.md#create-a-jira-issue-for-a-vulnerability) | **{check-circle}** Yes | **{dotted-circle}** No |
|
||||
| Create a GitLab branch from a Jira issue | **{dotted-circle}** No | **{check-circle}** Yes, in the issue's development panel |
|
||||
| Sync GitLab deployments to Jira issues | **{dotted-circle}** No | **{check-circle}** Yes, in the issue's development panel. Mention a Jira issue ID in a GitLab merge request, branch name, or any of the last 5,000 commits made to the branch after the last successful deployment to the environment |
|
||||
| Mention a Jira issue ID in a GitLab commit or merge request, and a link to the Jira issue is created. | **{check-circle}** Yes | **{dotted-circle}** No |
|
||||
| Mention a Jira issue ID in GitLab, and the Jira issue shows the GitLab issue or merge request. | **{check-circle}** Yes, a Jira comment with the GitLab issue or merge request title links to GitLab. The first mention is also added to **Web links** in the Jira issue. | **{check-circle}** Yes, in the Jira issue's [development panel](https://support.atlassian.com/jira-software-cloud/docs/view-development-information-for-an-issue/). |
|
||||
| Mention a Jira issue ID in a GitLab commit, and the Jira issue shows the commit message. | **{check-circle}** Yes, the entire commit message is displayed in the Jira issue as a comment and in **Web links**. Each message links back to the commit in GitLab. | **{check-circle}** Yes, in the Jira issue's development panel. A custom comment is possible with [Jira Smart Commits](https://confluence.atlassian.com/fisheye/using-smart-commits-960155400.html). |
|
||||
| Mention a Jira issue ID in a GitLab branch name, and the Jira issue shows the branch name. | **{dotted-circle}** No | **{check-circle}** Yes, in the Jira issue's development panel. |
|
||||
| Add time tracking to a Jira issue. | **{dotted-circle}** No | **{check-circle}** Yes, with Jira Smart Commits. |
|
||||
| Use a GitLab commit or merge request to transition a Jira issue. |**{check-circle}** Yes, only a single transition. Typically used to close the Jira issue. | **{check-circle}** Yes, transition the Jira issue to any state with Jira Smart Commits. |
|
||||
| [View a list of Jira issues](issues.md#view-jira-issues). | **{check-circle}** Yes | **{dotted-circle}** No |
|
||||
| [Create a Jira issue for a vulnerability](configure.md#create-a-jira-issue-for-a-vulnerability). | **{check-circle}** Yes | **{dotted-circle}** No |
|
||||
| Create a GitLab branch from a Jira issue. | **{dotted-circle}** No | **{check-circle}** Yes, in the Jira issue's development panel. |
|
||||
| Mention a Jira issue ID in a GitLab merge request, branch name, or any of the last 5,000 commits to the branch after the last successful deployment to the environment to sync a GitLab deployment to a Jira issue. | **{dotted-circle}** No | **{check-circle}** Yes, in the Jira issue's development panel. |
|
||||
|
||||
## Privacy considerations
|
||||
|
||||
All Jira integrations share data with Jira to make it visible outside of GitLab.
|
||||
If you integrate a private GitLab project with Jira, the private data is
|
||||
shared with users who have access to your Jira project.
|
||||
All Jira integrations share data outside of GitLab.
|
||||
If you integrate a private GitLab project with Jira, the private
|
||||
data is shared with users who have access to your Jira project.
|
||||
|
||||
The [Jira issue integration](configure.md) posts GitLab data in the form of comments in Jira issues.
|
||||
The GitLab for Jira Cloud app and Jira DVCS connector share this data through the [Jira development panel](development_panel.md).
|
||||
This method provides more fine-grained access control because access can be restricted to certain user groups or roles.
|
||||
The [Jira issue integration](configure.md) posts GitLab data as comments on Jira issues.
|
||||
The [GitLab for Jira Cloud app](connect-app.md) and the [Jira DVCS connector](dvcs/index.md)
|
||||
share GitLab data through the [Jira development panel](development_panel.md).
|
||||
With the Jira development panel, you can restrict access to certain user groups or roles.
|
||||
|
||||
## Related topics
|
||||
|
||||
|
||||
@ -285,9 +285,11 @@ findings, select **View full report** to go directly to the **Security** tab in
|
||||
|
||||
### Pipeline security tab
|
||||
|
||||
A pipeline's security tab lists all findings in the current branch. It includes new findings introduced by this branch
|
||||
and existing vulnerabilities already present when you created the branch. These results likely do not match the findings
|
||||
displayed in the Merge Request security widget, as those do not include the existing vulnerabilities. Refer to [View vulnerabilities in a pipeline](vulnerability_report/pipeline.md) for more information.
|
||||
A pipeline's security tab lists all findings in the current branch. It includes findings introduced
|
||||
by this branch and vulnerabilities already present in the base branch. These results likely do not
|
||||
match the findings displayed in the Merge Request security widget, as those do not include the
|
||||
existing vulnerabilities. For more information see
|
||||
[Vulnerabilities in a pipeline](vulnerability_report/pipeline.md).
|
||||
|
||||
### Security dashboard
|
||||
|
||||
|
||||
@ -4,50 +4,42 @@ group: Threat Insights
|
||||
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
|
||||
---
|
||||
|
||||
# View vulnerabilities in a pipeline
|
||||
# Vulnerabilities in a pipeline
|
||||
|
||||
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/13496) in GitLab 12.3.
|
||||
All enabled security analyzers run in the pipeline and output their results as artifacts. These
|
||||
artifacts are processed, including [deduplication](#deduplication-process), and the results are
|
||||
listed on the pipeline **Security** tab. By identifying vulnerability
|
||||
[findings](../terminology/index.md#finding) in a pipeline, you can address the risks
|
||||
proactively.
|
||||
|
||||
The following criteria apply to the pipeline security tab:
|
||||
|
||||
- The results of only successful security scan jobs are shown. For example, if a pipeline contains
|
||||
SAST and DAST jobs, but the DAST job fails, only the SAST results are shown.
|
||||
- If the pipeline has a [blocking manual job](../../../ci/jobs/job_control.md#types-of-manual-jobs),
|
||||
the pipeline waits for the manual job, and the vulnerabilities cannot be displayed if the blocking
|
||||
manual job did not run.
|
||||
- Findings have an expiry period. Expired findings are not shown on the pipeline security tab. For
|
||||
details, see [Retention period for findings](#retention-period-for-findings).
|
||||
|
||||
## View vulnerabilities in a pipeline
|
||||
|
||||
To view vulnerabilities in a pipeline:
|
||||
|
||||
1. On the left sidebar, select **Search or go to** and find your project.
|
||||
1. Select **Build > Pipelines**.
|
||||
1. From the list, select the pipeline you want to check for vulnerabilities.
|
||||
1. Select the pipeline.
|
||||
1. Select the **Security** tab.
|
||||
|
||||
A pipeline consists of multiple jobs, which may include security scans. When a job declares and produces security scan
|
||||
reports using [`artifacts:reports`](../../../ci/yaml/artifacts_reports.md), GitLab parses and ingests the contents of
|
||||
these reports to create vulnerabilities associated with the project the pipeline belongs to.
|
||||
|
||||
If a job fails to finish, the pipeline vulnerability report doesn't show vulnerability findings detected by this job.
|
||||
For example, if a pipeline contains DAST and SAST jobs, but the DAST job fails by returning a non-zero
|
||||
[exit code](../../../development/integrations/secure.md#exit-code), the report doesn't show DAST results.
|
||||
|
||||
The pipeline vulnerability report only shows results contained in the security report artifacts. This report differs from
|
||||
the [vulnerability report](index.md), which contains cumulative results of all successful jobs, and from the merge request
|
||||
[security widget](../index.md#merge-request), which contains new vulnerability findings that don't already exist on the default branch.
|
||||
|
||||
NOTE:
|
||||
If a new advisory is added to our advisory database and the last pipeline for the default branch is stale, the resulting vulnerability may appear in the MR widget as "New" when it is already in the default branch. This will be resolved by [Continuous Vulnerability Scans](https://gitlab.com/groups/gitlab-org/-/epics/7886).
|
||||
|
||||
The pipeline vulnerability report only displays after the pipeline is complete. If the pipeline has a [blocking manual job](../../../ci/jobs/job_control.md#types-of-manual-jobs), the pipeline waits for the manual job and the vulnerabilities cannot be displayed if the blocking manual job did not run.
|
||||
|
||||
Before GitLab displays results, the vulnerability findings in all pipeline reports are [deduplicated](#deduplication-process).
|
||||
|
||||
## Scan details
|
||||
|
||||
**Scan details** shows a summary of vulnerability findings in the pipeline and the source reports.
|
||||
The **Scan details** section shows a summary of vulnerability findings in the pipeline and the
|
||||
source reports.
|
||||
|
||||
GitLab displays one row of information for each [scan type](../terminology/index.md#scan-type-report-type) artifact present in
|
||||
the pipeline.
|
||||
GitLab displays one row of information for each [scan type](../terminology/index.md#scan-type-report-type)
|
||||
artifact present in the pipeline.
|
||||
|
||||
Each scan type's total number of vulnerabilities includes dismissed findings. If the number of findings
|
||||
in the report doesn't match the number in **Scan details**, ensure that **Hide dismissed** is disabled.
|
||||
|
||||
### Download security scan outputs
|
||||
|
||||
> - [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/3728) in GitLab 13.10.
|
||||
> - [Improved](https://gitlab.com/gitlab-org/gitlab/-/issues/333660) in GitLab 14.2.
|
||||
## Downloading security scan results
|
||||
|
||||
Depending on the type of security scanner, you can download:
|
||||
|
||||
@ -56,22 +48,32 @@ Depending on the type of security scanner, you can download:
|
||||
|
||||
To download a security scan output:
|
||||
|
||||
1. On the left sidebar, select **Search or go to** and find your project.
|
||||
1. Select **Build > Pipelines**.
|
||||
1. Select the pipeline.
|
||||
1. Select the **Security** tab.
|
||||
1. In **Scan details**, select **Download results**:
|
||||
- To download a JSON file, select the JSON artifact.
|
||||
- To download a CSV file, select **Download scanned resources**.
|
||||
- To download a JSON file, select the JSON artifact.
|
||||
- To download a CSV file, select **Download scanned resources**.
|
||||
|
||||
## Scan results
|
||||
|
||||
This shows a list of the combined results for all security report artifacts. The filters work like the
|
||||
[Vulnerability Report filters](index.md#vulnerability-report-filters), but they are limited to **Severity** and **Tool**, with
|
||||
the addition of a **Hide dismissed** toggle.
|
||||
Findings present in the source branch are listed in descending order of severity. You can filter the
|
||||
list of findings by severity and tool. You can also download the results of the security scans, for
|
||||
analysis outside GitLab.
|
||||
|
||||
When you review the vulnerability findings reported in the pipeline, you can select one or more entries for dismissal,
|
||||
similar to [dismissing a vulnerability](index.md#change-status-of-vulnerabilities) in the Vulnerability Report.
|
||||
Findings that are dismissed are hidden by default. To see these findings, turn off the
|
||||
**Hide dismissed** toggle.
|
||||
|
||||
When you merge the branch corresponding to the pipeline into the default branch, all reported findings are combined into
|
||||
the [Vulnerability Report](index.md). Scan results in pipelines executed on the default branch are
|
||||
incorporated once the pipeline finishes.
|
||||
For each finding you can:
|
||||
|
||||
- Get more information about the finding.
|
||||
- Create an issue for the finding.
|
||||
- Dismiss the finding.
|
||||
|
||||
When you merge the merge request's branch into the target branch, all reported findings are
|
||||
in the [vulnerability report](index.md). Scan results in pipelines executed on the
|
||||
default branch are incorporated after the pipeline finishes, according to the following table:
|
||||
|
||||
| Existing vulnerability status | Dismissed in pipeline? | New vulnerability status |
|
||||
|:------------------------------|:-----------------------|:-------------------------|
|
||||
@ -80,18 +82,18 @@ incorporated once the pipeline finishes.
|
||||
| Confirmed | No | Confirmed |
|
||||
| Needs triage (Detected) | No | Needs triage (Detected) |
|
||||
| Resolved | No | Needs triage (Detected) |
|
||||
| N/A (That is: new vulnerability) | No | Needs triage (Detected) |
|
||||
| N/A (New vulnerability) | No | Needs triage (Detected) |
|
||||
|
||||
## Retention period for vulnerabilities
|
||||
## Retention period for findings
|
||||
|
||||
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/351524) in GitLab 15.5.
|
||||
|
||||
GitLab has the following retention policies for vulnerabilities on non-default branches. Vulnerabilities are no longer available:
|
||||
Findings are no longer available:
|
||||
|
||||
- When the related CI job artifact expires.
|
||||
- 90 days after the pipeline is created, even if the related CI job artifacts are locked.
|
||||
|
||||
To view vulnerabilities, either:
|
||||
To view findings, either:
|
||||
|
||||
- Run a new pipeline.
|
||||
- Download the related CI job artifacts if they are available.
|
||||
@ -103,7 +105,7 @@ This does not apply for the vulnerabilities existing on the default branch.
|
||||
|
||||
When a pipeline contains jobs that produce multiple security reports of the same type, it is possible that the same
|
||||
vulnerability finding is present in multiple reports. This duplication is common when different scanners are used to
|
||||
increase coverage, but can also exist within a single report. The deduplication process allows you to maximize the vulnerability scanning coverage while reducing
|
||||
increase coverage, but can also exist in a single report. The deduplication process allows you to maximize the vulnerability scanning coverage while reducing
|
||||
the number of findings you need to manage.
|
||||
|
||||
A finding is considered a duplicate of another finding when their [scan type](../terminology/index.md#scan-type-report-type),
|
||||
|
||||
@ -58,6 +58,7 @@ To create a group access token:
|
||||
|
||||
1. On the left sidebar, select **Search or go to** and find your group.
|
||||
1. Select **Settings > Access Tokens**.
|
||||
1. Select **Add new token**.
|
||||
1. Enter a name. The token name is visible to any user with permissions to view the group.
|
||||
1. Enter an expiry date for the token:
|
||||
- The token expires on that date at midnight UTC.
|
||||
@ -120,7 +121,7 @@ To revoke a group access token:
|
||||
|
||||
1. On the left sidebar, select **Search or go to** and find your group.
|
||||
1. Select **Settings > Access Tokens**.
|
||||
1. Next to the group access token to revoke, select **Revoke**.
|
||||
1. Next to the group access token to revoke, select **Revoke** (**{remove}**).
|
||||
|
||||
## Revoke a group access token using Rails console
|
||||
|
||||
@ -162,6 +163,7 @@ To enable or disable group access token creation for all subgroups in a top-leve
|
||||
1. Select **Settings > General**.
|
||||
1. Expand **Permissions and group features**.
|
||||
1. Under **Permissions**, turn on or off **Users can create project access tokens and group access tokens in this group**.
|
||||
1. Select **Save changes**.
|
||||
|
||||
Even when creation is disabled, you can still use and revoke existing group access tokens.
|
||||
|
||||
|
||||
@ -177,6 +177,9 @@ describe('Manual Variables Form', () => {
|
||||
beforeEach(async () => {
|
||||
await createComponent({
|
||||
handlers: {
|
||||
getJobQueryResponseHandlerWithVariables: jest
|
||||
.fn()
|
||||
.mockResolvedValue(mockJobWithVariablesResponse),
|
||||
playJobMutationHandler: jest.fn().mockResolvedValue(mockJobPlayMutationData),
|
||||
},
|
||||
});
|
||||
@ -208,6 +211,15 @@ describe('Manual Variables Form', () => {
|
||||
expect(requestHandlers.playJobMutationHandler).toHaveBeenCalledTimes(1);
|
||||
expect(redirectTo).toHaveBeenCalledWith(mockJobPlayMutationData.data.jobPlay.job.webPath); // eslint-disable-line import/no-deprecated
|
||||
});
|
||||
|
||||
it('does not refetch variables after job is run', async () => {
|
||||
expect(requestHandlers.getJobQueryResponseHandlerWithVariables).toHaveBeenCalledTimes(1);
|
||||
|
||||
findRunBtn().vm.$emit('click');
|
||||
await waitForPromises();
|
||||
|
||||
expect(requestHandlers.getJobQueryResponseHandlerWithVariables).toHaveBeenCalledTimes(1);
|
||||
});
|
||||
});
|
||||
|
||||
describe('when play mutation is unsuccessful', () => {
|
||||
@ -234,6 +246,9 @@ describe('Manual Variables Form', () => {
|
||||
await createComponent({
|
||||
props: { isRetryable: true },
|
||||
handlers: {
|
||||
getJobQueryResponseHandlerWithVariables: jest
|
||||
.fn()
|
||||
.mockResolvedValue(mockJobWithVariablesResponse),
|
||||
retryJobMutationHandler: jest.fn().mockResolvedValue(mockJobRetryMutationData),
|
||||
},
|
||||
});
|
||||
@ -250,6 +265,15 @@ describe('Manual Variables Form', () => {
|
||||
expect(requestHandlers.retryJobMutationHandler).toHaveBeenCalledTimes(1);
|
||||
expect(redirectTo).toHaveBeenCalledWith(mockJobRetryMutationData.data.jobRetry.job.webPath); // eslint-disable-line import/no-deprecated
|
||||
});
|
||||
|
||||
it('does not refetch variables after job is rerun', async () => {
|
||||
expect(requestHandlers.getJobQueryResponseHandlerWithVariables).toHaveBeenCalledTimes(1);
|
||||
|
||||
findRunBtn().vm.$emit('click');
|
||||
await waitForPromises();
|
||||
|
||||
expect(requestHandlers.getJobQueryResponseHandlerWithVariables).toHaveBeenCalledTimes(1);
|
||||
});
|
||||
});
|
||||
|
||||
describe('when retry mutation is unsuccessful', () => {
|
||||
|
||||
Reference in New Issue
Block a user