提交 38ceebb9 编写于 作者: G GitLab Bot

Add latest changes from gitlab-org/gitlab@master

上级 0d09054d
<script>
import { GlTabs, GlTab } from '@gitlab/ui';
import { GlNewDropdown, GlNewDropdownItem, GlTabs, GlTab } from '@gitlab/ui';
import { s__ } from '~/locale';
export default {
statuses: {
triggered: s__('AlertManagement|Triggered'),
acknowledged: s__('AlertManagement|Acknowledged'),
resolved: s__('AlertManagement|Resolved'),
},
i18n: {
fullAlertDetailsTitle: s__('AlertManagement|Full Alert Details'),
overviewTitle: s__('AlertManagement|Overview'),
},
components: {
GlNewDropdown,
GlNewDropdownItem,
GlTab,
GlTabs,
},
......@@ -15,7 +22,18 @@ export default {
</script>
<template>
<div>
<div class="d-flex justify-content-between">
<div class="d-flex justify-content-between border-bottom pb-2 pt-1">
<gl-new-dropdown class="align-self-center" right>
<gl-new-dropdown-item
v-for="(label, field) in $options.statuses"
:key="field"
data-testid="statusDropdownItem"
class="align-middle"
>{{ label }}
</gl-new-dropdown-item>
</gl-new-dropdown>
</div>
<div class="d-flex">
<gl-tabs>
<gl-tab data-testid="overviewTab" :title="$options.i18n.overviewTitle">
<ul class="pl-3">
......
......@@ -63,15 +63,22 @@ export function getParameterValues(sParam, url = window.location) {
}, []);
}
// @param {Object} params - url keys and value to merge
// @param {String} url
/**
* Merges a URL to a set of params replacing value for
* those already present.
*
* Also removes `null` param values from the resulting URL.
*
* @param {Object} params - url keys and value to merge
* @param {String} url
*/
export function mergeUrlParams(params, url) {
const re = /^([^?#]*)(\?[^#]*)?(.*)/;
const merged = {};
const urlparts = url.match(re);
const [, fullpath, query, fragment] = url.match(re);
if (urlparts[2]) {
urlparts[2]
if (query) {
query
.substr(1)
.split('&')
.forEach(part => {
......@@ -84,11 +91,15 @@ export function mergeUrlParams(params, url) {
Object.assign(merged, params);
const query = Object.keys(merged)
const newQuery = Object.keys(merged)
.filter(key => merged[key] !== null)
.map(key => `${encodeURIComponent(key)}=${encodeURIComponent(merged[key])}`)
.join('&');
return `${urlparts[1]}?${query}${urlparts[3]}`;
if (newQuery) {
return `${fullpath}?${newQuery}${fragment}`;
}
return `${fullpath}${fragment}`;
}
/**
......
......@@ -486,8 +486,7 @@ module Ci
end
def requires_resource?
Feature.enabled?(:ci_resource_group, project, default_enabled: true) &&
self.resource_group_id.present?
self.resource_group_id.present?
end
def has_environment?
......
......@@ -68,21 +68,11 @@ module UpdateProjectStatistics
def schedule_update_project_statistic(delta)
return if delta.zero?
return if project.nil?
if Feature.enabled?(:update_project_statistics_after_commit, default_enabled: true)
# Update ProjectStatistics after the transaction
run_after_commit do
ProjectStatistics.increment_statistic(
project_id, self.class.project_statistics_name, delta)
end
else
# Use legacy-way to update within transaction
run_after_commit do
ProjectStatistics.increment_statistic(
project_id, self.class.project_statistics_name, delta)
end
run_after_commit do
next if project.nil?
Namespaces::ScheduleAggregationWorker.perform_async(
project.namespace_id)
......
......@@ -98,9 +98,9 @@
.form-check
= f.check_box :web_ide_clientside_preview_enabled, class: 'form-check-input'
= f.label :web_ide_clientside_preview_enabled, class: 'form-check-label' do
= s_('IDE|Client side evaluation')
= s_('IDE|Live Preview')
%span.form-text.text-muted
= s_('IDE|Allow live previews of JavaScript projects in the Web IDE using CodeSandbox client side evaluation.')
= s_('IDE|Allow live previews of JavaScript projects in the Web IDE using CodeSandbox Live Preview.')
= f.submit _('Save changes'), class: "btn btn-success"
......
---
title: "Rename Client Side Evaluation to Live Preview"
merge_request: 30309
author:
type: changed
---
title: Handle Snippet file name errors in backfill
merge_request: 30981
author:
type: fixed
......@@ -19,4 +19,5 @@ swap:
rspec: RSpec
self hosted: self-managed
self-hosted: self-managed
x509: X.509
yaml: YAML
......@@ -286,7 +286,7 @@ The following documentation relates to the DevOps **Release** stage:
| [Canary Deployments](user/project/canary_deployments.md) **(PREMIUM)** | Employ a popular CI strategy where a small portion of the fleet is updated to the new version first. |
| [Deploy Boards](user/project/deploy_boards.md) **(PREMIUM)** | View the current health and status of each CI environment running on Kubernetes, displaying the status of the pods in the deployment. |
| [Environments and deployments](ci/environments.md) | With environments, you can control the continuous deployment of your software within GitLab. |
| [Environment-specific variables](ci/variables/README.md#limiting-environment-scopes-of-environment-variables) | Limit the scope of variables to specific environments. |
| [Environment-specific variables](ci/variables/README.md#limit-the-environment-scopes-of-environment-variables) | Limit the scope of variables to specific environments. |
| [GitLab CI/CD](ci/README.md) | Explore the features and capabilities of Continuous Deployment and Delivery with GitLab. |
| [GitLab Pages](user/project/pages/index.md) | Build, test, and deploy a static site directly from GitLab. |
| [Protected Runners](ci/runners/README.md#protected-runners) | Select Runners to only pick jobs for protected branches and tags. |
......@@ -315,7 +315,7 @@ The following documentation relates to the DevOps **Configure** stage:
| [Installing Applications](user/project/clusters/index.md#installing-applications) | Deploy Helm, Ingress, and Prometheus on Kubernetes. |
| [Mattermost slash commands](user/project/integrations/mattermost_slash_commands.md) | Enable and use slash commands from within Mattermost. |
| [Multiple Kubernetes Clusters](user/project/clusters/index.md#multiple-kubernetes-clusters-premium) **(PREMIUM)** | Associate more than one Kubernetes clusters to your project. |
| [Protected variables](ci/variables/README.md#protected-environment-variables) | Restrict variables to protected branches and tags. |
| [Protected variables](ci/variables/README.md#protect-a-custom-variable) | Restrict variables to protected branches and tags. |
| [Serverless](user/project/clusters/serverless/index.md) | Run serverless workloads on Kubernetes. |
| [Slack slash commands](user/project/integrations/slack_slash_commands.md) | Enable and use slash commands from within Slack. |
| [Manage your infrastructure with Terraform](user/infrastructure/index.md) | Manage your infrastructure as you run your CI/CD pipeline. |
......
......@@ -15,7 +15,11 @@ All administrators at the time of creation of the project and group will be adde
as maintainers of the group and project, and as an admin, you'll be able to add new
members to the group in order to give them maintainer access to the project.
This project will be used for self monitoring your GitLab instance.
This project is used to self monitor your GitLab instance. Metrics are not yet
fully integrated, and the dashboard does not aggregate any data on Omnibus installations. GitLab plans
to provide integrated self-monitoring metrics in a future release. You can
currently use the project to configure your own [custom metrics](../../../user/project/integrations/prometheus.md#adding-custom-metrics) using
metrics exposed by the [GitLab exporter](../prometheus/gitlab_metrics.md#metrics-available).
## Creating the self monitoring project
......
......@@ -214,6 +214,20 @@ p.each do |project|
end
```
### Bulk update to disable the Slack Notification service
To disable notifications for all projects that have Slack service enabled, do:
```ruby
# Grab all projects that have the Slack notifications enabled
p = Project.find_by_sql("SELECT p.id FROM projects p LEFT JOIN services s ON p.id = s.project_id WHERE s.type = 'SlackService' AND s.active = true")
# Disable the service on each of the projects that were found.
p.each do |project|
project.slack_service.update_attribute(:active, false)
end
```
## Wikis
### Recreate
......
......@@ -454,6 +454,12 @@ The resulting cURL call for a project with id `5` and a group id of `17` is then
curl --request DELETE --header "PRIVATE-TOKEN: <your_access_token>" https://gitlab.example.com/api/v4/projects/5/share/17
```
NOTE: **Note:**
Path parameters that are required to be URL-encoded must be followed. If not,
it will not match an API endpoint and respond with a 404. If there's something
in front of the API (for example, Apache), ensure that it won't decode the URL-encoded
path parameters.
## Namespaced path encoding
If using namespaced API calls, make sure that the `NAMESPACE/PROJECT_PATH` is
......@@ -470,15 +476,16 @@ A project's **path** is not necessarily the same as its **name**. A
project's path can be found in the project's URL or in the project's settings
under **General > Advanced > Change path**.
## Branches and tags name encoding
## File path, branches, and tags name encoding
If your branch or tag contains a `/`, make sure the branch/tag name is
URL-encoded.
If a file path, branch or tag contains a `/`, make sure it is URL-encoded.
For example, `/` is represented by `%2F`:
```plaintext
GET /api/v4/projects/1/repository/files/src%2FREADME.md?ref=master
GET /api/v4/projects/1/branches/my%2Fbranch/commits
GET /api/v4/projects/1/repository/tags/my%2Ftag
```
## Encoding API parameters of `array` and `hash` types
......
......@@ -755,7 +755,7 @@ Example response if commit is GPG signed:
}
```
Example response if commit is x509 signed:
Example response if commit is X.509 signed:
```json
{
......
# Feature Flag User Lists API **(PREMIUM)**
# Feature flag user lists API **(PREMIUM)**
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/205409) in [GitLab Premium](https://about.gitlab.com/pricing/) 12.10.
......@@ -63,7 +63,7 @@ POST /projects/:id/feature_flags_user_lists
| ------------------- | ---------------- | ---------- | ---------------------------------------------------------------------------------------|
| `id` | integer/string | yes | The ID or [URL-encoded path of the project](README.md#namespaced-path-encoding). |
| `name` | string | yes | The name of the feature flag. |
| `user_xids` | string | yes | A comma separated list of user ids. |
| `user_xids` | string | yes | A comma separated list of user IDs. |
```shell
curl https://gitlab.example.com/api/v4/projects/1/feature_flags_user_lists \
......@@ -122,6 +122,47 @@ Example response:
}
```
## Update a feature flag user list
Updates a feature flag user list.
```plaintext
PUT /projects/:id/feature_flags_user_lists/:iid
```
| Attribute | Type | Required | Description |
| ------------------- | ---------------- | ---------- | ---------------------------------------------------------------------------------------|
| `id` | integer/string | yes | The ID or [URL-encoded path of the project](README.md#namespaced-path-encoding). |
| `iid` | integer/string | yes | The internal ID of the project's feature flag user list. |
| `name` | string | no | The name of the feature flag. |
| `user_xids` | string | no | A comma separated list of user IDs. |
```shell
curl https://gitlab.example.com/api/v4/projects/1/feature_flags_user_lists/1 \
--header "PRIVATE-TOKEN: <your_access_token>" \
--header "Content-type: application/json" \
--request PUT \
--data @- << EOF
{
"user_xids": "user2,user3,user4"
}
EOF
```
Example response:
```json
{
"name": "my_user_list",
"user_xids": "user2,user3,user4",
"id": 1,
"iid": 1,
"project_id": 1,
"created_at": "2020-02-04T08:32:27.288Z",
"updated_at": "2020-02-05T09:33:17.179Z"
}
```
## Delete feature flag user list
Deletes a feature flag user list.
......
......@@ -364,7 +364,7 @@ are listed in the descriptions of the relevant settings.
| `user_oauth_applications` | boolean | no | Allow users to register any application to use GitLab as an OAuth provider. |
| `user_show_add_ssh_key_message` | boolean | no | When set to `false` disable the "You won't be able to pull or push project code via SSH" warning shown to users with no uploaded SSH key. |
| `version_check_enabled` | boolean | no | Let GitLab inform you when an update is available. |
| `web_ide_clientside_preview_enabled` | boolean | no | Client side evaluation (allow live previews of JavaScript projects in the Web IDE using CodeSandbox client side evaluation). |
| `web_ide_clientside_preview_enabled` | boolean | no | Live Preview (allow live previews of JavaScript projects in the Web IDE using CodeSandbox Live Preview). |
| `snippet_size_limit` | integer | no | Max snippet content size in **bytes**. Default: 52428800 Bytes (50MB).|
| `issues_create_limit` | integer | no | Max number of issue creation requests per minute per user. Default: 300. To disable throttling set to 0.|
| `raw_blob_request_limit` | integer | no | Max number of requests per minute for each raw path. Default: 300. To disable throttling set to 0.|
......@@ -925,7 +925,7 @@ with `review/` would have that particular variable.
Some GitLab features can behave differently for each environment.
For example, you can
[create a secret variable to be injected only into a production environment](variables/README.md#limiting-environment-scopes-of-environment-variables).
[create a secret variable to be injected only into a production environment](variables/README.md#limit-the-environment-scopes-of-environment-variables).
In most cases, these features use the _environment specs_ mechanism, which offers
an efficient way to implement scoping within each environment group.
......
......@@ -74,5 +74,5 @@ in the `.gitlab-ci.yml` file with your application's name.
## Heroku API key
You can look up your Heroku API key in your
[account](https://dashboard.heroku.com/account). Add a [protected variable](../variables/README.md#protected-environment-variables) with
[account](https://dashboard.heroku.com/account). Add a [protected variable](../variables/README.md#protect-a-custom-variable) with
this value in **Project ➔ Variables** with key `HEROKU_API_KEY`.
......@@ -282,7 +282,7 @@ my_job:
In GitLab, we use the [`variables` keyword](../yaml/README.md#variables) to define different variables at runtime.
These can also be set up through the GitLab UI, under CI/CD settings. See also our [general documentation on variables](../variables/README.md),
including the section on [protected variables](../variables/README.md#protected-environment-variables) which can be used
including the section on [protected variables](../variables/README.md#protect-a-custom-variable) which can be used
to limit access to certain variables to certain environments or runners:
```yaml
......
......@@ -74,7 +74,7 @@ You can also configure specific aspects of your pipelines through the GitLab UI.
- [Pipeline settings](settings.md) for each project.
- [Pipeline schedules](schedules.md).
- [Custom CI/CD variables](../variables/README.md#creating-a-custom-environment-variable).
- [Custom CI/CD variables](../variables/README.md#custom-environment-variables).
### View pipelines
......@@ -373,7 +373,7 @@ the pipeline view, *not* the play (**{play}**) button.
This is useful when you want to alter the execution of a job that uses
[custom environment variables](../variables/README.md#custom-environment-variables).
Adding a variable name (key) and value here will override the value defined in
[the UI or `.gitlab-ci.yml`](../variables/README.md#creating-a-custom-environment-variable),
[the UI or `.gitlab-ci.yml`](../variables/README.md#custom-environment-variables),
for a single run of the manual job.
![Manual job variables](img/manual_job_variables.png)
......
......@@ -27,7 +27,7 @@ variables:
NOTE: **Note:**
The `MYSQL_DATABASE` and `MYSQL_ROOT_PASSWORD` variables can't be set in the GitLab UI.
To set them, assign them to a variable [in the UI](../variables/README.md#via-the-ui),
To set them, assign them to a variable [in the UI](../variables/README.md#create-a-custom-variable-in-the-ui),
and then assign that variable to the
`MYSQL_DATABASE` and `MYSQL_ROOT_PASSWORD` variables in your `.gitlab-ci.yml`.
......
......@@ -29,7 +29,7 @@ variables:
NOTE: **Note:**
The `POSTGRES_DB`, `POSTGRES_USER`, `POSTGRES_PASSWORD` and `POSTGRES_HOST_AUTH_METHOD`
variables can't be set in the GitLab UI. To set them, assign them to a variable
[in the UI](../variables/README.md#via-the-ui), and then assign that
[in the UI](../variables/README.md#create-a-custom-variable-in-the-ui), and then assign that
variable to the `POSTGRES_DB`, `POSTGRES_USER`, `POSTGRES_PASSWORD` and `POSTGRES_HOST_AUTH_METHOD`
variables in your `.gitlab-ci.yml`.
......
此差异已折叠。
......@@ -897,7 +897,7 @@ In this example, if the first rule:
`rules:if` differs slightly from `only:variables` by accepting only a single
expression string, rather than an array of them. Any set of expressions to be
evaluated should be conjoined into a single expression using `&&` or `||`, and use
the [variable matching syntax](../variables/README.md#supported-syntax).
the [variable matching syntax](../variables/README.md#syntax-of-environment-variable-expressions).
For example:
......
......@@ -145,7 +145,7 @@ at GitLab so far:
fork. That way the danger comments will be made from CI using that
API token instead.
Making the variable
[masked](../ci/variables/README.md#masked-variables) will make sure
[masked](../ci/variables/README.md#mask-a-custom-variable) will make sure
it doesn't show up in the job logs. The variable cannot be
[protected](../ci/variables/README.md#protected-environment-variables),
[protected](../ci/variables/README.md#protect-a-custom-variable),
as it needs to be present for all feature branches.
......@@ -3,7 +3,8 @@
- **Write the code and the tests.**: As with any code, EE features should have
good test coverage to prevent regressions.
- **Write documentation.**: Add documentation to the `doc/` directory. Describe
the feature and include screenshots, if applicable.
the feature and include screenshots, if applicable. Indicate [what editions](documentation/styleguide.md#product-badges)
the feature applies to.
- **Submit a MR to the `www-gitlab-com` project.**: Add the new feature to the
[EE features list](https://about.gitlab.com/features/).
......
......@@ -56,7 +56,7 @@ The author then adds a comment to this piece of code and adds a link to the issu
- Track necessary events. See the [telemetry guide](../../telemetry/index.md) for details.
- After the merge request is merged, use [`chatops`](../../ci/chatops/README.md) in the
[appropriate channel](../feature_flags/controls.md#where-to-run-commands) to start the experiment for 10% of the users.
[appropriate channel](../feature_flags/controls.md#communicate-the-change) to start the experiment for 10% of the users.
The feature flag should have the name of the experiment with the `_experiment_percentage` suffix appended.
For visibility, please also share any commands run against production in the `#s_growth` channel:
......
......@@ -16,32 +16,6 @@ run:
/chatops run feature --help
```
## Where to run commands
To increase visibility, we recommend that GitLab team members run feature flag
related Chatops commands within certain Slack channels based on the environment
and related feature. For the [staging](https://staging.gitlab.com)
and [development](https://dev.gitlab.org) environments of GitLab.com,
the commands should run in a channel for the stage the feature is relevant too.
For example, use the `#s_monitor` channel for features developed by the
Monitor stage, Health group.
For all production environment Chatops commands, use the `#production` channel.
As per the template, where a feature would have a (potentially) significant user
impact and the feature is being enabled instance wide prior to release, please copy
the Slack message and repost in the `#support_gitlab-com` channel for added visibility
and awareness, preferably with a link to the issue, MR, or docs.
Regardless of the channel in which the Chatops command is ran, any feature flag change that affects GitLab.com will automatically be logged in an issue.
The issue is created in the [gl-infra/feature-flag-log](https://gitlab.com/gitlab-com/gl-infra/feature-flag-log/issues?scope=all&utf8=%E2%9C%93&state=closed) project, and it will at minimum log the Slack handle of person enabling a feature flag, the time, and the name of the flag being changed.
The issue is then also posted to GitLab Inc. internal [Grafana dashboard](https://dashboards.gitlab.net/) as an annotation marker to make the change even more visible.
Changes to the issue format can be submitted in the [Chatops project](https://gitlab.com/gitlab-com/chatops).
## Rolling out changes
When the changes are deployed to the environments it is time to start
......@@ -67,19 +41,11 @@ If you get an error "Whoops! This action is not allowed. This incident
will be reported." that means your Slack account is not allowed to
change feature flags or you do not [have access](#access).
### Enabling feature for preproduction testing
### Enabling a feature for preproduction testing
As a first step in a feature rollout, you should enable the feature on <https://staging.gitlab.com>
and <https://dev.gitlab.org>.
For example, to enable a feature for 25% of all users, run the following in
Slack:
```shell
/chatops run feature set new_navigation_bar 25 --dev
/chatops run feature set new_navigation_bar 25 --staging
```
These two environments have different scopes.
`dev.gitlab.org` is a production CE environment that has internal GitLab Inc.
traffic and is used for some development and other related work.
......@@ -89,13 +55,65 @@ a (very) rough estimate of how your feature will look/behave on GitLab.com.
Both of these instances are connected to Sentry so make sure you check the projects
there for any exceptions while testing your feature after enabling the feature flag.
Once you are confident enough that these environments are in a good state with your
feature enabled, you can roll out the change to GitLab.com.
For these preproduction environments, the commands should be run in a
Slack channel for the stage the feature is relevant to. For example, use the
`#s_monitor` channel for features developed by the Monitor stage, Health
group.
To enable a feature for 25% of all users, run the following in Slack:
```shell
/chatops run feature set new_navigation_bar 25 --dev
/chatops run feature set new_navigation_bar 25 --staging
```
### Enabling a feature for GitLab.com
Similar to above, to enable a feature for 25% of all users, run the following in
Slack:
When a feature has successfully been
[enabled on a preproduction](#enabling-a-feature-for-preproduction-testing)
environment and verified as safe and working, you can roll out the
change to GitLab.com (production).
#### Communicate the change
Some feature flag changes on GitLab.com should be communicated with
parts of the company. The developer responsible needs to determine
whether this is necessary and the appropriate level of communication.
This depends on the feature and what sort of impact it might have.
As a guideline:
- For simple features that are low-risk, and easily rolled back, then
just proceed to [enabling the feature in `#production`](#process).
- For features that will impact user experience consider notifying
`#support_gitlab-com` beforehand.
- For features with significant downstream effects (e.g.: turning on/off
Elasticsearch indexing) consider coordinating with `#production`
beforehand.
#### Process
Before toggling any feature flag, check that there are no ongoing
significant incidents on GitLab.com. You can do this by checking the
`#production` and `#incident-management` Slack channels, or looking for
[open incident issues](https://gitlab.com/gitlab-com/gl-infra/production/issues/?scope=all&utf8=%E2%9C%93&state=opened&label_name[]=incident)
(although check the dates and times).
We do not want to introduce changes during an incident, as it can make
diagnosis and resolution of the incident much harder to achieve, and
also will largely invalidate your rollout process as you will be unable
to assess whether the rollout was without problems or not.
If there is any doubt, ask in `#production`.
The following `/chatops` commands should be performed in the Slack
`#production` channel.
When you begin to enable the feature, please link to the relevant
Feature Flag Rollout Issue within a Slack thread of the first `/chatops`
command you make so people can understand the change if they need to.
To enable a feature for 25% of all users, run the following in Slack:
```shell
/chatops run feature set new_navigation_bar 25
......@@ -150,6 +168,23 @@ NOTE: **Note:**
**Percentage of time** rollout is not a good idea if what you want is to make sure a feature
is always on or off to the users.
### Feature flag change logging
Any feature flag change that affects GitLab.com (production) will
automatically be logged in an issue.
The issue is created in the
[gl-infra/feature-flag-log](https://gitlab.com/gitlab-com/gl-infra/feature-flag-log/issues?scope=all&utf8=%E2%9C%93&state=closed)
project, and it will at minimum log the Slack handle of person enabling
a feature flag, the time, and the name of the flag being changed.
The issue is then also posted to GitLab's internal
[Grafana dashboard](https://dashboards.gitlab.net/) as an annotation
marker to make the change even more visible.
Changes to the issue format can be submitted in the
[Chatops project](https://gitlab.com/gitlab-com/chatops).
## Cleaning up
Once the change is deemed stable, submit a new merge request to remove the
......
......@@ -42,66 +42,6 @@ For all of the above, please include `--why "Reason"` and `--who "My Name"` so t
More detailed information on how the gem and its commands work is available in the [License Finder README](https://github.com/pivotal/LicenseFinder).
## Acceptable Licenses
## Additional information
Libraries with the following licenses are acceptable for use:
- [MIT License](https://choosealicense.com/licenses/mit/) (the MIT Expat License specifically): The MIT License requires that the license itself is included with all copies of the source. It is a permissive (non-copyleft) license as defined by the Open Source Initiative.
- [GNU Lesser General Public License (GNU LGPL)](https://choosealicense.com/licenses/lgpl-3.0/) (version 2, version 3): GPL constraints regarding modification and redistribution under the same license are not required of projects using an LGPL library, only upon modification of the LGPL-licensed library itself.
- [Apache 2.0 License](https://choosealicense.com/licenses/apache-2.0/): A permissive license that also provides an express grant of patent rights from contributors to users.
- [Ruby 1.8 License](https://github.com/ruby/ruby/blob/ruby_1_8_6/COPYING): Dual-licensed under either itself or the GPLv2, defer to the Ruby License itself. Acceptable because of point 3b: "You may distribute the software in object code or binary form, provided that you do at least ONE of the following: b) accompany the distribution with the machine-readable source of the software."
- [Ruby 1.9 License](https://www.ruby-lang.org/en/about/license.txt): Dual-licensed under either itself or the BSD 2-Clause License, defer to BSD 2-Clause.
- [BSD 2-Clause License](https://opensource.org/licenses/BSD-2-Clause): A permissive (non-copyleft) license as defined by the Open Source Initiative.
- [BSD 3-Clause License](https://opensource.org/licenses/BSD-3-Clause) (also known as New BSD or Modified BSD): A permissive (non-copyleft) license as defined by the Open Source Initiative
- [ISC License](https://opensource.org/licenses/ISC) (also known as the OpenBSD License): A permissive (non-copyleft) license as defined by the Open Source Initiative.
- [Creative Commons Zero (CC0)](https://creativecommons.org/publicdomain/zero/1.0/): A public domain dedication, recommended as a way to disclaim copyright on your work to the maximum extent possible.
- [Unlicense](https://unlicense.org): Another public domain dedication.
- [OWFa 1.0](http://www.openwebfoundation.org/legal/the-owf-1-0-agreements/owfa-1-0): An open-source license and patent grant designed for specifications.
- [JSON License](https://www.json.org/license.html): Equivalent to the MIT license plus the statement, "The Software shall be used for Good, not Evil."
## Unacceptable Licenses
Libraries with the following licenses require legal approval for use:
- [GNU GPL](https://choosealicense.com/licenses/gpl-3.0/) (version 1, [version 2](http://www.gnu.org/licenses/gpl-2.0.txt), [version 3](http://www.gnu.org/licenses/gpl-3.0.txt), or any future versions): GPL-licensed libraries cannot be linked to from non-GPL projects.
- [GNU AGPLv3](https://choosealicense.com/licenses/agpl-3.0/): AGPL-licensed libraries cannot be linked to from non-GPL projects.
- [Open Software License (OSL)](https://opensource.org/licenses/OSL-3.0): is a copyleft license. In addition, the FSF [recommend against its use](https://www.gnu.org/licenses/license-list.en.html#OSL).
- [WTFPL](https://wtfpl.net): is a public domain dedication [rejected by the OSI (3.2)](https://opensource.org/minutes20090304). Also has a strong language which is not in accordance with our diversity policy.
## GPL Cooperation Commitment
Before filing or continuing to prosecute any legal proceeding or claim (other than a Defensive Action) arising from termination of a Covered License, GitLab commits to extend to the person or entity (“you”) accused of violating the Covered License the following provisions regarding cure and reinstatement, taken from GPL version 3. As used here, the term ‘this License’ refers to the specific Covered License being enforced.
However, if you cease all violation of this License, then your license from a particular copyright holder is reinstated (a) provisionally, unless and until the copyright holder explicitly and finally terminates your license, and (b) permanently, if the copyright holder fails to notify you of the violation by some reasonable means prior to 60 days after the cessation.
Moreover, your license from a particular copyright holder is reinstated permanently if the copyright holder notifies you of the violation by some reasonable means, this is the first time you have received notice of violation of this License (for any work) from that copyright holder, and you cure the violation prior to 30 days after your receipt of the notice.
GitLab intends this Commitment to be irrevocable, and binding and enforceable against GitLab and assignees of or successors to GitLab’s copyrights.
GitLab may modify this Commitment by publishing a new edition on this page or a successor location.
Definitions
‘Covered License’ means the GNU General Public License, version 2 (GPLv2), the GNU Lesser General Public License, version 2.1 (LGPLv2.1), or the GNU Library General Public License, version 2 (LGPLv2), all as published by the Free Software Foundation.
‘Defensive Action’ means a legal proceeding or claim that GitLab brings against you in response to a prior proceeding or claim initiated by you or your affiliate.
GitLab means GitLab Inc. and its affiliates and subsidiaries.
## Requesting Approval for Licenses or any other Intellectual Property
Libraries that are not already approved and listed on the [Acceptable Licenses](#acceptable-licenses) list or that may be listed on the [Unacceptable Licenses](#unacceptable-licenses) list may be submitted to the legal team for review and use on a case-by-case basis. Please email `legal@gitlab.com` with the details of how the software will be used, whether or not it will be modified, and how it will be distributed (if at all). After a decision has been made, the original requestor is responsible for updating this document, if applicable. Not all approvals will be approved for universal use and may continue to remain on the Unacceptable License list.
All inquiries relating to patents should be directed to the Legal team.
## Notes
Decisions regarding the GNU GPL licenses are based on information provided by [The GNU Project](http://www.gnu.org/licenses/gpl-faq.html#IfLibraryIsGPL), as well as [the Open Source Initiative](https://opensource.org/faq#linking-proprietary-code), which both state that linking GPL libraries makes the program itself GPL.
If a gem uses a license which is not listed above, open an issue and ask. If a license is not included in the "acceptable" list, operate under the assumption that it is not acceptable.
Keep in mind that each license has its own restrictions (typically defined in their body text). Please make sure to comply with those restrictions at all times whenever an external library is used.
Dependencies which are only used in development or test environment are exempt from license requirements, as they're not distributed for use in production.
**NOTE:** This document is **not** legal advice, nor is it comprehensive. It should not be taken as such.
Please see the [Open Source](https://about.gitlab.com/handbook/engineering/open-source/#using-open-source-libraries) page for more information on licensing.
......@@ -43,11 +43,18 @@ you want the branches to start with a certain name because you have different
GitLab CI/CD jobs (`feature`, `hotfix`, `docker`, `android`, etc.) that rely on the
branch name.
Your developers however, don't always remember that policy, so they push
various branches and CI pipelines do not work as expected. By restricting the
branch names globally in Push Rules, you can now sleep without the anxiety
of your developers' mistakes. Every branch that doesn't match your push rule
will get rejected.
Your developers, however, don't always remember that policy, so they might push to
various branches, and CI pipelines might not work as expected. By restricting the
branch names globally in Push Rules, such mistakes are prevented.
Any branch name that doesn't match your push rule will get rejected.
Note that the name of your default branch is always allowed, regardless of the branch naming
regular expression (regex) specified. GitLab is configured this way
because merges typically have the default branch as their target.
If you have other target branches, include them in your regex. (See [Enabling push rules](#enabling-push-rules)).
The default branch also defaults to being a [protected branch](../user/project/protected_branches.md),
which already limits users from pushing directly.
### Custom Push Rules **(CORE ONLY)**
......
......@@ -37,4 +37,4 @@ The following are available Rake tasks:
| [Uploads sanitize](../administration/raketasks/uploads/sanitize.md) | Remove EXIF data from images uploaded to earlier versions of GitLab. |
| [User management](user_management.md) | Perform user management tasks. |
| [Webhooks administration](web_hooks.md) | Maintain project Webhooks. |
| [X509 signatures](x509_signatures.md) | Update x509 commit signatures, useful if certificate store has changed. |
| [X.509 signatures](x509_signatures.md) | Update X.509 commit signatures, useful if certificate store has changed. |
# X509 signatures **(CORE ONLY)**
# X.509 signatures **(CORE ONLY)**
When [signing commits with x509](../user/project/repository/x509_signed_commits/index.md),
When [signing commits with X.509](../user/project/repository/x509_signed_commits/index.md),
the trust anchor might change and the signatures stored within the database must be updated.
## Update all x509 signatures
## Update all X.509 signatures
This task loops through all X509 signed commits and updates their verification based on current
This task loops through all X.509 signed commits and updates their verification based on current
certificate store.
To update all x509 signatures, run:
To update all X.509 signatures, run:
**Omnibus Installation**
......
......@@ -76,7 +76,7 @@ The next step is to tell the offline instance to use these resources instead of
and so on.
You can set these variables in the project's `.gitlab-ci.yml` files by using the bundle directly, or
in the GitLab UI at the project or group level. See the [GitLab CI/CD environment variables page](../../ci/variables/README.md#creating-a-custom-environment-variable)
in the GitLab UI at the project or group level. See the [GitLab CI/CD environment variables page](../../ci/variables/README.md#custom-environment-variables)
for more information.
#### Variables
......
......@@ -146,7 +146,7 @@ to override the default chart values by setting `HELM_UPGRADE_EXTRA_ARGS` to `--
## Custom Helm chart per environment
You can specify the use of a custom Helm chart per environment by scoping the environment variable
to the desired environment. See [Limiting environment scopes of variables](../../ci/variables/README.md#limiting-environment-scopes-of-environment-variables).
to the desired environment. See [Limiting environment scopes of variables](../../ci/variables/README.md#limit-the-environment-scopes-of-environment-variables).
## Customizing `.gitlab-ci.yml`
......
......@@ -348,7 +348,7 @@ used by Auto DevOps currently defines 3 environment names:
Those environments are tied to jobs using [Auto Deploy](stages.md#auto-deploy), so
except for the environment scope, they must have a different deployment domain.
You must define a separate `KUBE_INGRESS_BASE_DOMAIN` variable for each of the above
[based on the environment](../../ci/variables/README.md#limiting-environment-scopes-of-environment-variables).
[based on the environment](../../ci/variables/README.md#limit-the-environment-scopes-of-environment-variables).
The following table is an example of how to configure the three different clusters:
......
......@@ -25,7 +25,7 @@ Access the default page for admin area settings by navigating to
| [Terms of Service and Privacy Policy](terms.md) | Include a Terms of Service agreement and Privacy Policy that all users must accept. |
| [External Authentication](external_authorization.md#configuration) | External Classification Policy Authorization |
| [Web terminal](../../../administration/integration/terminal.md#limiting-websocket-connection-time) | Set max session time for web terminal. |
| [Web IDE](../../project/web_ide/index.md#enabling-client-side-evaluation) | Manage Web IDE Features. |
| [Web IDE](../../project/web_ide/index.md#enabling-live-preview) | Manage Web IDE Features. |
## Integrations
......
......@@ -233,6 +233,7 @@ but commented out to help encourage others to add to it in the future. -->
|protected_branches|counts||
|releases|counts||
|remote_mirrors|counts||
|requirements_created|counts||
|snippets|counts||
|suggestions|counts||
|todos|counts||
......
......@@ -259,7 +259,7 @@ to pass a username and password. You can set it under your project's settings
so that your credentials aren't exposed in `.gitlab-ci.yml`.
If the username is `myuser` and the password is `verysecret` then you would
[set the following variable](../../ci/variables/README.md#via-the-ui)
[set the following variable](../../ci/variables/README.md#create-a-custom-variable-in-the-ui)
under your project's settings:
| Type | Key | Value |
......
......@@ -354,7 +354,7 @@ Some analyzers can be customized with environment variables.
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/18193) in GitLab Ultimate 12.5.
In addition to the aforementioned SAST configuration variables,
all [custom environment variables](../../../ci/variables/README.md#creating-a-custom-environment-variable) are propagated
all [custom environment variables](../../../ci/variables/README.md#custom-environment-variables) are propagated
to the underlying SAST analyzer images if
[the SAST vendored template](#configuration) is used.
......
......@@ -157,7 +157,7 @@ can be used for:
- Downloading assets from a CDN
- Any other commands that must run before the `git init`
To use this feature, define a [CI/CD variable](../../ci/variables/README.md#via-the-ui) called
To use this feature, define a [CI/CD variable](../../ci/variables/README.md#create-a-custom-variable-in-the-ui) called
`CI_PRE_CLONE_SCRIPT` that contains a bash script.
[This example](../../development/pipelines.md#pre-clone-step)
......
......@@ -106,7 +106,7 @@ The domain should have a wildcard DNS configured to the Ingress IP address.
When adding more than one Kubernetes cluster to your project, you need to differentiate
them with an environment scope. The environment scope associates clusters with
[environments](../../../ci/environments.md) similar to how the
[environment-specific variables](../../../ci/variables/README.md#limiting-environment-scopes-of-environment-variables)
[environment-specific variables](../../../ci/variables/README.md#limit-the-environment-scopes-of-environment-variables)
work.
While evaluating which environment matches the environment scope of a
......
......@@ -300,7 +300,7 @@ GitLab [isn't limited to the SAML providers listed above](#my-identity-provider-
| SAML Request Binding | HTTP Redirect | GitLab (the service provider) redirects users to your Identity Provider with a base64 encoded `SAMLRequest` HTTP parameter. |
| SAML Response Binding | HTTP POST | Your Identity Provider responds to users with an HTTP form including the `SAMLResponse`, which a user's browser submits back to GitLab. |
| Sign SAML Response | Yes | We require this to prevent tampering. |
| X509 Certificate in response | Yes | This is used to sign the response and checked against the provided fingerprint. |
| X.509 Certificate in response | Yes | This is used to sign the response and checked against the provided fingerprint. |
| Fingerprint Algorithm | SHA-1 | We need a SHA-1 hash of the certificate used to sign the SAML Response. |
| Signature Algorithm | SHA-1/SHA-256/SHA-384/SHA-512 | Also known as the Digest Method, this can be specified in the SAML response. It determines how a response is signed. |
| Encrypt SAML Assertion | No | TLS is used between your Identity Provider, the user's browser, and GitLab. |
......
......@@ -182,7 +182,7 @@ you can either:
When adding more than one Kubernetes cluster to your project, you need to differentiate
them with an environment scope. The environment scope associates clusters with [environments](../../../ci/environments.md) similar to how the
[environment-specific variables](../../../ci/variables/README.md#limiting-environment-scopes-of-environment-variables) work.
[environment-specific variables](../../../ci/variables/README.md#limit-the-environment-scopes-of-environment-variables) work.
The default environment scope is `*`, which means all jobs, regardless of their
environment, will use that cluster. Each scope can only be used by a single
......@@ -262,7 +262,7 @@ A Kubernetes cluster can be the destination for a deployment job. If
the cluster from your jobs using tools such as `kubectl` or `helm`.
- You don't use GitLab's cluster integration you can still deploy to your
cluster. However, you will need configure Kubernetes tools yourself
using [environment variables](../../../ci/variables/README.md#creating-a-custom-environment-variable)
using [environment variables](../../../ci/variables/README.md#custom-environment-variables)
before you can interact with the cluster from your jobs.
### Deployment variables
......
......@@ -134,7 +134,7 @@ the components outlined above and the pre-loaded demo runbook.
1. Navigate to **{settings}** **Settings >> CI/CD >> Variables** to create
the variables in your project.
![GitLab variables](img/gitlab-variables.png)
![GitLab variables](img/gitlab-variables.png)
1. Click **Save variables**.
......
......@@ -937,7 +937,7 @@ Prerequisites for embedding from a Grafana instance:
You can set the visibility of the metrics dashboard to **Only Project Members**
or **Everyone With Access**. When set to **Everyone with Access**, the metrics
dashboard, and all of the custom dashboard, YAML files, are visible to authenticated and non-authenticated users.
dashboard is visible to authenticated and non-authenticated users.
## Troubleshooting
......
......@@ -2,17 +2,17 @@
type: concepts, howto
---
# Signing commits with x509
# Signing commits with X.509
[x509](https://en.wikipedia.org/wiki/X.509) is a standard format for public key
[X.509](https://en.wikipedia.org/wiki/X.509) is a standard format for public key
certificates issued by a public or private Public Key Infrastructure (PKI).
Personal x509 certificates are used for authentication or signing purposes
Personal X.509 certificates are used for authentication or signing purposes
such as SMIME, but Git also supports signing of commits and tags
with x509 certificates in a similar way as with [GPG](../gpg_signed_commits/index.md).
The main difference is the trust anchor which is the PKI for x509 certificates
with X.509 certificates in a similar way as with [GPG](../gpg_signed_commits/index.md).
The main difference is the trust anchor which is the PKI for X.509 certificates
instead of a web of trust with GPG.
## How GitLab handles x509
## How GitLab handles X.509
GitLab uses its own certificate store and therefore defines the trust chain.
......@@ -27,7 +27,7 @@ For a commit to be *verified* by GitLab:
NOTE: **Note:** Certificate revocation lists are checked on a daily basis via background worker.
## Obtaining an x509 key pair
## Obtaining an X.509 key pair
If your organization has Public Key Infrastructure (PKI), that PKI will provide
an S/MIME key.
......@@ -37,9 +37,9 @@ own self-signed one, or purchase one. MozillaZine keeps a nice collection
of [S/MIME-capable signing authorities](http://kb.mozillazine.org/Getting_an_SMIME_certificate)
and some of them generate keys for free.
## Associating your x509 certificate with Git
## Associating your X.509 certificate with Git
To take advantage of X509 signing, you will need Git 2.19.0 or later. You can
To take advantage of X.509 signing, you will need Git 2.19.0 or later. You can
check your Git version with:
```sh
......@@ -64,7 +64,7 @@ Install [smimesign](https://github.com/github/smimesign) by downloading the
installer or via `brew install smimesign` on MacOS.
Get the ID of your certificate with `smimesign --list-keys` and set your
signingkey `git config --global user.signingkey ID`, then configure x509:
signingkey `git config --global user.signingkey ID`, then configure X.509:
```sh
git config --global gpg.x509.program smimesign
......@@ -73,7 +73,7 @@ git config --global gpg.format x509
## Signing commits
After you have [associated your x509 certificate with Git](#associating-your-x509-certificate-with-git) you
After you have [associated your X.509 certificate with Git](#associating-your-x509-certificate-with-git) you
can start signing your commits:
1. Commit like you used to, the only difference is the addition of the `-S` flag:
......
......@@ -102,27 +102,28 @@ in the top of the sidebar to open a list of branches.
You will need to commit or discard all your changes before switching to a
different branch.
## Client Side Evaluation
## Live Preview
> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/19764) in [GitLab Core](https://about.gitlab.com/pricing/) 11.2.
> - [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/19764) in [GitLab Core](https://about.gitlab.com/pricing/) 11.2.
> - [Renamed](https://gitlab.com/gitlab-org/gitlab/-/issues/213853) from _Client Side Evaluation_ to _Live Preview_ in GitLab 13.0.
You can use the Web IDE to preview JavaScript projects right in the browser.
This feature uses CodeSandbox to compile and bundle the JavaScript used to
preview the web application.
![Web IDE Client Side Evaluation](img/clientside_evaluation.png)
![Web IDE Live Preview](img/live_preview_v13_0.png)
Additionally, for public projects an **Open in CodeSandbox** button is available
to transfer the contents of the project into a public CodeSandbox project to
quickly share your project with others.
### Enabling Client Side Evaluation
### Enabling Live Preview
The Client Side Evaluation feature needs to be enabled in the GitLab instances
admin settings. Client Side Evaluation is enabled for all projects on
The Live Preview feature needs to be enabled in the GitLab instances
admin settings. Live Preview is enabled for all projects on
GitLab.com
![Admin Client Side Evaluation setting](img/admin_clientside_evaluation.png)
![Admin Live Preview setting](img/admin_live_preview_v13_0.png)
Once you have done that, you can preview projects with a `package.json` file and
a `main` entry point inside the Web IDE. An example `package.json` is shown
......
......@@ -126,7 +126,7 @@ found. The list is ordered alphabetically.
![Wiki sidebar](img/wiki_sidebar.png)
If you have many pages, not all will be listed in the sidebar. Click on
**More pages** to see all of them.
**View All Pages** to see all of them.
## Viewing the history of a wiki page
......@@ -189,7 +189,24 @@ instructions.
On the project's Wiki page, there is a right side navigation that renders the full Wiki pages list by default, with hierarchy.
If the Wiki repository contains a `_sidebar` page, the file of this page replaces the default side navigation.
This custom file serves to render it's custom content, fully replacing the standard sidebar.
To customize the sidebar, you can create a file named `_sidebar` to fully replace the default navigation.
CAUTION: **Warning:**
Unless you link the `_sidebar` file from your custom nav, to edit it you'll have to access it directly
from the browser's address bar by typing: `https://gitlab.com/<namespace>/<project_name>/-/wikis/_sidebar` (for self-managed GitLab instances, replace `gitlab.com` with your instance's URL).
Example for `_sidebar` (using Markdown format):
```markdown
### [Home](home)
- [Hello World](hello)
- [Foo](foo)
- [Bar](bar)
---
- [Sidebar](_sidebar)
```
Support for displaying a generated TOC with a custom side navigation is planned.
......@@ -15,12 +15,15 @@ module Gitlab
next if repository_present?(snippet)
retry_index = 0
@invalid_path_error = false
begin
create_repository_and_files(snippet)
logger.info(message: 'Snippet Migration: repository created and migrated', snippet: snippet.id)
rescue => e
set_file_path_error(e)
retry_index += 1
retry if retry_index < MAX_RETRIES
......@@ -73,7 +76,10 @@ module Gitlab
end
def filename(snippet)
snippet.file_name.presence || empty_file_name
file_name = snippet.file_name
file_name = file_name.parameterize if @invalid_path_error
file_name.presence || empty_file_name
end
def empty_file_name
......@@ -104,6 +110,15 @@ module Gitlab
def admin_user
@admin_user ||= User.admins.active.first
end
# We sometimes receive invalid path errors from Gitaly if the Snippet filename
# cannot be parsed into a valid git path.
# In this situation, we need to parameterize the file name of the Snippet so that
# the migration can succeed, to achieve that, we'll identify in migration retries
# that the path is invalid
def set_file_path_error(error)
@invalid_path_error = error.message.downcase.start_with?('invalid path', 'path cannot include directory traversal')
end
end
end
end
......@@ -9,7 +9,8 @@ module Gitlab
{
junit: ::Gitlab::Ci::Parsers::Test::Junit,
cobertura: ::Gitlab::Ci::Parsers::Coverage::Cobertura,
terraform: ::Gitlab::Ci::Parsers::Terraform::Tfplan
terraform: ::Gitlab::Ci::Parsers::Terraform::Tfplan,
accessibility: ::Gitlab::Ci::Parsers::Accessibility::Pa11y
}
end
......
# frozen_string_literal: true
module Gitlab
module Ci
module Parsers
module Accessibility
class Pa11y
def parse!(json_data, accessibility_report)
root = Gitlab::Json.parse(json_data)
parse_all(root, accessibility_report)
rescue JSON::ParserError => e
accessibility_report.set_error_message("JSON parsing failed: #{e}")
rescue StandardError => e
accessibility_report.set_error_message("Pa11y parsing failed: #{e}")
end
private
def parse_all(root, accessibility_report)
return unless root.present?
root.dig("results").each do |url, value|
accessibility_report.add_url(url, value)
end
accessibility_report
end
end
end
end
end
end
......@@ -16,7 +16,6 @@ module Gitlab
end
def to_resource
return unless Feature.enabled?(:ci_resource_group, build.project, default_enabled: true)
return unless resource_group_key.present?
resource_group = build.project.resource_groups
......
......@@ -4,20 +4,37 @@ module Gitlab
module Ci
module Reports
class AccessibilityReports
attr_accessor :total, :passes, :errors
attr_reader :urls
attr_reader :urls, :error_message
def initialize
@urls = {}
@total = 0
@passes = 0
@errors = 0
@error_message = nil
end
def add_url(url, data)
return if url.empty?
if url.empty?
set_error_message("Empty URL detected in gl-accessibility.json")
else
urls[url] = data
end
end
def scans_count
@urls.size
end
def passes_count
@urls.count { |url, errors| errors.empty? }
end
# rubocop: disable CodeReuse/ActiveRecord
def errors_count
@urls.sum { |url, errors| errors.size }
end
# rubocop: enable CodeReuse/ActiveRecord
urls[url] = data
def set_error_message(error)
@error_message = error
end
end
end
......
......@@ -11018,15 +11018,12 @@ msgstr ""
msgid "ID:"
msgstr ""
msgid "IDE|Allow live previews of JavaScript projects in the Web IDE using CodeSandbox client side evaluation."
msgid "IDE|Allow live previews of JavaScript projects in the Web IDE using CodeSandbox Live Preview."
msgstr ""
msgid "IDE|Back"
msgstr ""
msgid "IDE|Client side evaluation"
msgstr ""
msgid "IDE|Commit"
msgstr ""
......
......@@ -30,5 +30,9 @@ describe('AlertDetails', () => {
it('renders alert details', () => {
expect(wrapper.find('[data-testid="startTimeItem"]').exists()).toBe(true);
});
it('renders a status dropdown', () => {
expect(wrapper.find('[data-testid="statusDropdownItem"]').exists()).toBe(true);
});
});
});
......@@ -313,7 +313,7 @@ describe('DiffsStoreActions', () => {
describe('fetchDiffFilesMeta', () => {
it('should fetch diff meta information', done => {
const endpointMetadata = '/fetch/diffs_meta?';
const endpointMetadata = '/fetch/diffs_meta';
const mock = new MockAdapter(axios);
const data = { diff_files: [] };
const res = { data };
......
......@@ -91,36 +91,75 @@ describe('URL utility', () => {
});
describe('mergeUrlParams', () => {
const { mergeUrlParams } = urlUtils;
it('adds w', () => {
expect(urlUtils.mergeUrlParams({ w: 1 }, '#frag')).toBe('?w=1#frag');
expect(urlUtils.mergeUrlParams({ w: 1 }, '/path#frag')).toBe('/path?w=1#frag');
expect(urlUtils.mergeUrlParams({ w: 1 }, 'https://host/path')).toBe('https://host/path?w=1');
expect(urlUtils.mergeUrlParams({ w: 1 }, 'https://host/path#frag')).toBe(
'https://host/path?w=1#frag',
);
expect(mergeUrlParams({ w: 1 }, '#frag')).toBe('?w=1#frag');
expect(mergeUrlParams({ w: 1 }, '')).toBe('?w=1');
expect(mergeUrlParams({ w: 1 }, '/path#frag')).toBe('/path?w=1#frag');
expect(mergeUrlParams({ w: 1 }, 'https://host/path')).toBe('https://host/path?w=1');
expect(mergeUrlParams({ w: 1 }, 'https://host/path#frag')).toBe('https://host/path?w=1#frag');
expect(mergeUrlParams({ w: 1 }, 'https://h/p?k1=v1#frag')).toBe('https://h/p?k1=v1&w=1#frag');
expect(mergeUrlParams({ w: 'null' }, '')).toBe('?w=null');
});
expect(urlUtils.mergeUrlParams({ w: 1 }, 'https://h/p?k1=v1#frag')).toBe(
'https://h/p?k1=v1&w=1#frag',
);
it('adds multiple params', () => {
expect(mergeUrlParams({ a: 1, b: 2, c: 3 }, '#frag')).toBe('?a=1&b=2&c=3#frag');
});
it('updates w', () => {
expect(urlUtils.mergeUrlParams({ w: 1 }, '?k1=v1&w=0#frag')).toBe('?k1=v1&w=1#frag');
expect(mergeUrlParams({ w: 2 }, '/path?w=1#frag')).toBe('/path?w=2#frag');
expect(mergeUrlParams({ w: 2 }, 'https://host/path?w=1')).toBe('https://host/path?w=2');
});
it('adds multiple params', () => {
expect(urlUtils.mergeUrlParams({ a: 1, b: 2, c: 3 }, '#frag')).toBe('?a=1&b=2&c=3#frag');
it('removes null w', () => {
expect(mergeUrlParams({ w: null }, '?w=1#frag')).toBe('#frag');
expect(mergeUrlParams({ w: null }, '/path?w=1#frag')).toBe('/path#frag');
expect(mergeUrlParams({ w: null }, 'https://host/path?w=1')).toBe('https://host/path');
expect(mergeUrlParams({ w: null }, 'https://host/path?w=1#frag')).toBe(
'https://host/path#frag',
);
expect(mergeUrlParams({ w: null }, 'https://h/p?k1=v1&w=1#frag')).toBe(
'https://h/p?k1=v1#frag',
);
});
it('adds and updates encoded params', () => {
expect(urlUtils.mergeUrlParams({ a: '&', q: '?' }, '?a=%23#frag')).toBe('?a=%26&q=%3F#frag');
it('adds and updates encoded param values', () => {
expect(mergeUrlParams({ foo: '&', q: '?' }, '?foo=%23#frag')).toBe('?foo=%26&q=%3F#frag');
expect(mergeUrlParams({ foo: 'a value' }, '')).toBe('?foo=a%20value');
expect(mergeUrlParams({ foo: 'a value' }, '?foo=1')).toBe('?foo=a%20value');
});
it('adds and updates encoded param names', () => {
expect(mergeUrlParams({ 'a name': 1 }, '')).toBe('?a%20name=1');
expect(mergeUrlParams({ 'a name': 2 }, '?a%20name=1')).toBe('?a%20name=2');
expect(mergeUrlParams({ 'a name': null }, '?a%20name=1')).toBe('');
});
it('treats "+" as "%20"', () => {
expect(urlUtils.mergeUrlParams({ ref: 'bogus' }, '?a=lorem+ipsum&ref=charlie')).toBe(
expect(mergeUrlParams({ ref: 'bogus' }, '?a=lorem+ipsum&ref=charlie')).toBe(
'?a=lorem%20ipsum&ref=bogus',
);
});
it('treats question marks and slashes as part of the query', () => {
expect(mergeUrlParams({ ending: '!' }, '?ending=?&foo=bar')).toBe('?ending=!&foo=bar');
expect(mergeUrlParams({ ending: '!' }, 'https://host/path?ending=?&foo=bar')).toBe(
'https://host/path?ending=!&foo=bar',
);
expect(mergeUrlParams({ ending: '?' }, '?ending=!&foo=bar')).toBe('?ending=%3F&foo=bar');
expect(mergeUrlParams({ ending: '?' }, 'https://host/path?ending=!&foo=bar')).toBe(
'https://host/path?ending=%3F&foo=bar',
);
expect(mergeUrlParams({ ending: '!', op: '+' }, '?ending=?&op=/')).toBe('?ending=!&op=%2B');
expect(mergeUrlParams({ ending: '!', op: '+' }, 'https://host/path?ending=?&op=/')).toBe(
'https://host/path?ending=!&op=%2B',
);
expect(mergeUrlParams({ op: '+' }, '?op=/&foo=bar')).toBe('?op=%2B&foo=bar');
expect(mergeUrlParams({ op: '+' }, 'https://host/path?op=/&foo=bar')).toBe(
'https://host/path?op=%2B&foo=bar',
);
});
});
describe('removeParams', () => {
......
......@@ -177,6 +177,48 @@ describe Gitlab::BackgroundMigration::BackfillSnippetRepositories, :migration, s
end
end
end
context 'with invalid file names' do
using RSpec::Parameterized::TableSyntax
where(:invalid_file_name, :converted_file_name) do
'filename.js // with comment' | 'filename-js-with-comment'
'.git/hooks/pre-commit' | 'git-hooks-pre-commit'
'https://gitlab.com' | 'https-gitlab-com'
'html://web.title%mp4/mpg/mpeg.net' | 'html-web-title-mp4-mpg-mpeg-net'
'../../etc/passwd' | 'etc-passwd'
'.' | 'snippetfile1.txt'
end
with_them do
let!(:snippet_with_invalid_path) { snippets.create(id: 4, type: 'PersonalSnippet', author_id: user.id, file_name: invalid_file_name, content: content) }
let!(:snippet_with_valid_path) { snippets.create(id: 5, type: 'PersonalSnippet', author_id: user.id, file_name: file_name, content: content) }
let(:ids) { [4, 5] }
after do
raw_repository(snippet_with_invalid_path).remove
raw_repository(snippet_with_valid_path).remove
end
it 'checks for file path errors when errors are raised' do
expect(service).to receive(:set_file_path_error).once.and_call_original
subject
end
it 'converts invalid filenames' do
subject
expect(blob_at(snippet_with_invalid_path, converted_file_name)).to be
end
it 'does not convert valid filenames on subsequent migrations' do
subject
expect(blob_at(snippet_with_valid_path, file_name)).to be
end
end
end
end
def blob_at(snippet, path)
......
# frozen_string_literal: true
require 'fast_spec_helper'
describe Gitlab::Ci::Parsers::Accessibility::Pa11y do
describe '#parse!' do
subject { described_class.new.parse!(pa11y, accessibility_report) }
let(:accessibility_report) { Gitlab::Ci::Reports::AccessibilityReports.new }
context "when data is pa11y style JSON" do
context "when there are no URLs provided" do
let(:pa11y) do
{
"total": 1,
"passes": 0,
"errors": 0,
"results": {
"": [
{
"message": "Protocol error (Page.navigate): Cannot navigate to invalid URL"
}
]
}
}.to_json
end
it "returns an accessibility report" do
expect { subject }.not_to raise_error
expect(accessibility_report.errors_count).to eq(0)
expect(accessibility_report.passes_count).to eq(0)
expect(accessibility_report.scans_count).to eq(0)
expect(accessibility_report.urls).to be_empty
expect(accessibility_report.error_message).to eq("Empty URL detected in gl-accessibility.json")
end
end
context "when there are no errors" do
let(:pa11y) do
{
"total": 1,
"passes": 1,
"errors": 0,
"results": {
"http://pa11y.org/": []
}
}.to_json
end
it "returns an accessibility report" do
expect { subject }.not_to raise_error
expect(accessibility_report.urls['http://pa11y.org/']).to be_empty
expect(accessibility_report.errors_count).to eq(0)
expect(accessibility_report.passes_count).to eq(1)
expect(accessibility_report.scans_count).to eq(1)
end
end
context "when there are errors" do
let(:pa11y) do
{
"total": 1,
"passes": 0,
"errors": 1,
"results": {
"https://about.gitlab.com/": [
{
"code": "WCAG2AA.Principle4.Guideline4_1.4_1_2.H91.A.NoContent",
"type": "error",
"typeCode": 1,
"message": "Anchor element found with a valid href attribute, but no link content has been supplied.",
"context": "<a href=\"/\" class=\"navbar-brand animated\"><svg height=\"36\" viewBox=\"0 0 1...</a>",
"selector": "#main-nav > div:nth-child(1) > a",
"runner": "htmlcs",
"runnerExtras": {}
}
]
}
}.to_json
end
it "returns an accessibility report" do
expect { subject }.not_to raise_error
expect(accessibility_report.errors_count).to eq(1)
expect(accessibility_report.passes_count).to eq(0)
expect(accessibility_report.scans_count).to eq(1)
expect(accessibility_report.urls['https://about.gitlab.com/']).to be_present
end
end
end
context "when data is not a valid JSON string" do
let(:pa11y) do
{
"total": 1,
"passes": 1,
"errors": 0,
"results": {
"http://pa11y.org/": []
}
}
end
it "sets error_message" do
expect { subject }.not_to raise_error
expect(accessibility_report.error_message).to include('Pa11y parsing failed')
expect(accessibility_report.errors_count).to eq(0)
expect(accessibility_report.passes_count).to eq(0)
expect(accessibility_report.scans_count).to eq(0)
end
end
end
end
......@@ -22,6 +22,14 @@ describe Gitlab::Ci::Parsers do
end
end
context 'when file_type is accessibility' do
let(:file_type) { 'accessibility' }
it 'fabricates the class' do
is_expected.to be_a(described_class::Accessibility::Pa11y)
end
end
context 'when file_type is terraform' do
let(:file_type) { 'terraform' }
......
......@@ -4,37 +4,144 @@ require 'spec_helper'
describe Gitlab::Ci::Reports::AccessibilityReports do
let(:accessibility_report) { described_class.new }
let(:url) { 'https://gitlab.com' }
let(:data) do
[
{
"code": "WCAG2AA.Principle4.Guideline4_1.4_1_2.H91.A.NoContent",
"type": "error",
"typeCode": 1,
"message": "Anchor element found with a valid href attribute, but no link content has been supplied.",
"context": "<a href=\"/customers/worldline\">\n<svg viewBox=\"0 0 509 89\" xmln...</a>",
"selector": "html > body > div:nth-child(9) > div:nth-child(2) > a:nth-child(17)",
"runner": "htmlcs",
"runnerExtras": {}
},
{
"code": "WCAG2AA.Principle4.Guideline4_1.4_1_2.H91.A.NoContent",
"type": "error",
"typeCode": 1,
"message": "Anchor element found with a valid href attribute, but no link content has been supplied.",
"context": "<a href=\"/customers/equinix\">\n<svg xmlns=\"http://www.w3.org/...</a>",
"selector": "html > body > div:nth-child(9) > div:nth-child(2) > a:nth-child(18)",
"runner": "htmlcs",
"runnerExtras": {}
}
]
end
describe '#add_url' do
subject { accessibility_report.add_url(url, data) }
describe '#scans_count' do
subject { accessibility_report.scans_count }
context 'when data has errors' do
let(:different_url) { 'https://about.gitlab.com' }
before do
accessibility_report.add_url(url, data)
accessibility_report.add_url(different_url, data)
end
it 'returns the scans_count' do
expect(subject).to eq(2)
end
end
context 'when data has no errors' do
before do
accessibility_report.add_url(url, [])
end
it 'returns the scans_count' do
expect(subject).to eq(1)
end
end
context 'when data has no url' do
before do
accessibility_report.add_url("", [])
end
it 'returns the scans_count' do
expect(subject).to eq(0)
end
end
end
describe '#passes_count' do
subject { accessibility_report.passes_count }
context 'when data has errors' do
before do
accessibility_report.add_url(url, data)
end
it 'returns the passes_count' do
expect(subject).to eq(0)
end
end
context 'when data has no errors' do
before do
accessibility_report.add_url(url, [])
end
it 'returns the passes_count' do
expect(subject).to eq(1)
end
end
context 'when data has no url' do
before do
accessibility_report.add_url("", [])
end
it 'returns the scans_count' do
expect(subject).to eq(0)
end
end
end
describe '#errors_count' do
subject { accessibility_report.errors_count }
context 'when data has errors' do
let(:url) { 'https://gitlab.com' }
let(:data) do
[
{
"code": "WCAG2AA.Principle4.Guideline4_1.4_1_2.H91.A.NoContent",
"type": "error",
"typeCode": 1,
"message": "Anchor element found with a valid href attribute, but no link content has been supplied.",
"context": "<a href=\"/customers/worldline\">\n<svg viewBox=\"0 0 509 89\" xmln...</a>",
"selector": "html > body > div:nth-child(9) > div:nth-child(2) > a:nth-child(17)",
"runner": "htmlcs",
"runnerExtras": {}
},
{
"code": "WCAG2AA.Principle4.Guideline4_1.4_1_2.H91.A.NoContent",
"type": "error",
"typeCode": 1,
"message": "Anchor element found with a valid href attribute, but no link content has been supplied.",
"context": "<a href=\"/customers/equinix\">\n<svg xmlns=\"http://www.w3.org/...</a>",
"selector": "html > body > div:nth-child(9) > div:nth-child(2) > a:nth-child(18)",
"runner": "htmlcs",
"runnerExtras": {}
}
]
let(:different_url) { 'https://about.gitlab.com' }
before do
accessibility_report.add_url(url, data)
accessibility_report.add_url(different_url, data)
end
it 'returns the errors_count' do
expect(subject).to eq(4)
end
end
context 'when data has no errors' do
before do
accessibility_report.add_url(url, [])
end
it 'returns the errors_count' do
expect(subject).to eq(0)
end
end
context 'when data has no url' do
before do
accessibility_report.add_url("", [])
end
it 'returns the errors_count' do
expect(subject).to eq(0)
end
end
end
describe '#add_url' do
subject { accessibility_report.add_url(url, data) }
context 'when data has errors' do
it 'adds urls and data to accessibility report' do
expect { subject }.not_to raise_error
......@@ -44,7 +151,6 @@ describe Gitlab::Ci::Reports::AccessibilityReports do
end
context 'when data does not have errors' do
let(:url) { 'https://gitlab.com' }
let(:data) { [] }
it 'adds data to accessibility report' do
......@@ -59,10 +165,37 @@ describe Gitlab::Ci::Reports::AccessibilityReports do
let(:url) { '' }
let(:data) { [{ message: "Protocol error (Page.navigate): Cannot navigate to invalid URL" }] }
it 'do not add data to accessibility report' do
it 'sets error_message and decreases total' do
expect { subject }.not_to raise_error
expect(accessibility_report.urls).to be_empty
expect(accessibility_report.scans_count).to eq(0)
expect(accessibility_report.error_message).to eq('Empty URL detected in gl-accessibility.json')
end
end
end
describe '#set_error_message' do
let(:set_accessibility_error) { accessibility_report.set_error_message('error') }
context 'when error is nil' do
it 'returns the error' do
expect(set_accessibility_error).to eq('error')
end
it 'sets the error' do
set_accessibility_error
expect(accessibility_report.error_message).to eq('error')
end
end
context 'when a error has already been set' do
before do
accessibility_report.set_error_message('old error')
end
it 'overwrites the existing message' do
expect { set_accessibility_error }.to change(accessibility_report, :error_message).from('old error').to('error')
end
end
end
......
......@@ -19,24 +19,8 @@ describe Ci::JobArtifact do
it_behaves_like 'having unique enum values'
context 'with update_project_statistics_after_commit enabled' do
before do
stub_feature_flags(update_project_statistics_after_commit: true)
end
it_behaves_like 'UpdateProjectStatistics' do
subject { build(:ci_job_artifact, :archive, size: 107464) }
end
end
context 'with update_project_statistics_after_commit disabled' do
before do
stub_feature_flags(update_project_statistics_after_commit: false)
end
it_behaves_like 'UpdateProjectStatistics' do
subject { build(:ci_job_artifact, :archive, size: 107464) }
end
it_behaves_like 'UpdateProjectStatistics' do
subject { build(:ci_job_artifact, :archive, size: 107464) }
end
describe '.with_reports' do
......
Markdown is supported
0% .
You are about to add 0 people to the discussion. Proceed with caution.
先完成此消息的编辑!
想要评论请 注册