diff options
55 files changed, 691 insertions, 161 deletions
diff --git a/app/assets/javascripts/environments/components/environments_app.vue b/app/assets/javascripts/environments/components/environments_app.vue index ce84caeb28f..b6a7cce36e9 100644 --- a/app/assets/javascripts/environments/components/environments_app.vue +++ b/app/assets/javascripts/environments/components/environments_app.vue @@ -143,13 +143,7 @@ export default { <confirm-rollback-modal :environment="environmentInRollbackModal" /> <div class="gl-w-full"> - <div - class=" - gl-display-flex - gl-flex-direction-column - gl-mt-3 - gl-display-md-none!" - > + <div class="gl-display-flex gl-flex-direction-column gl-mt-3 gl-display-md-none!"> <gl-button v-if="state.reviewAppDetails.can_setup_review_app" v-gl-modal="$options.modal.id" @@ -158,18 +152,16 @@ export default { category="secondary" type="button" class="gl-mb-3 gl-flex-fill-1" + >{{ $options.i18n.reviewAppButtonLabel }}</gl-button > - {{ $options.i18n.reviewAppButtonLabel }} - </gl-button> <gl-button v-if="canCreateEnvironment" :href="newEnvironmentPath" data-testid="new-environment" category="primary" variant="success" + >{{ $options.i18n.newEnvironmentButtonLabel }}</gl-button > - {{ $options.i18n.newEnvironmentButtonLabel }} - </gl-button> </div> <gl-tabs content-class="gl-display-none"> <gl-tab @@ -185,14 +177,7 @@ export default { </gl-tab> <template #tabs-end> <div - class=" - gl-display-none - gl-display-md-flex - gl-lg-align-items-center - gl-lg-flex-direction-row - gl-lg-flex-fill-1 - gl-lg-justify-content-end - gl-lg-mt-0" + class="gl-display-none gl-display-md-flex gl-lg-align-items-center gl-lg-flex-direction-row gl-lg-flex-fill-1 gl-lg-justify-content-end gl-lg-mt-0" > <gl-button v-if="state.reviewAppDetails.can_setup_review_app" @@ -202,18 +187,16 @@ export default { category="secondary" type="button" class="gl-mb-3 gl-lg-mr-3 gl-lg-mb-0" + >{{ $options.i18n.reviewAppButtonLabel }}</gl-button > - {{ $options.i18n.reviewAppButtonLabel }} - </gl-button> <gl-button v-if="canCreateEnvironment" :href="newEnvironmentPath" data-testid="new-environment" category="primary" variant="success" + >{{ $options.i18n.newEnvironmentButtonLabel }}</gl-button > - {{ $options.i18n.newEnvironmentButtonLabel }} - </gl-button> </div> </template> </gl-tabs> diff --git a/app/assets/javascripts/environments/components/environments_table.vue b/app/assets/javascripts/environments/components/environments_table.vue index 3cfff686c01..d13c7204285 100644 --- a/app/assets/javascripts/environments/components/environments_table.vue +++ b/app/assets/javascripts/environments/components/environments_table.vue @@ -15,6 +15,7 @@ export default { CanaryDeploymentCallout: () => import('ee_component/environments/components/canary_deployment_callout.vue'), EnvironmentAlert: () => import('ee_component/environments/components/environment_alert.vue'), + CanaryUpdateModal: () => import('ee_component/environments/components/canary_update_modal.vue'), }, props: { environments: { @@ -58,6 +59,12 @@ export default { default: '', }, }, + data() { + return { + canaryWeight: 0, + environmentToChange: null, + }; + }, computed: { sortedEnvironments() { return this.sortEnvironments(this.environments).map(env => @@ -144,11 +151,16 @@ export default { sortBy(env => (env.isFolder ? -1 : 1)), )(environments); }, + changeCanaryWeight(model, weight) { + this.environmentToChange = model; + this.canaryWeight = weight; + }, }, }; </script> <template> <div class="ci-table" role="grid"> + <canary-update-modal :environment="environmentToChange" :weight="canaryWeight" /> <div class="gl-responsive-table-row table-row-header" role="row"> <div class="table-section" :class="tableData.name.spacing" role="columnheader"> {{ tableData.name.title }} @@ -179,6 +191,7 @@ export default { :model="model" :can-read-environment="canReadEnvironment" :table-data="tableData" + data-qa-selector="environment_item" /> <div @@ -193,6 +206,7 @@ export default { :is-loading="model.isLoadingDeployBoard" :is-empty="model.isEmptyDeployBoard" :logs-path="model.logs_path" + @changeCanaryWeight="changeCanaryWeight(model, $event)" /> </div> </div> @@ -215,6 +229,7 @@ export default { :model="children" :can-read-environment="canReadEnvironment" :table-data="tableData" + data-qa-selector="environment_item" /> <div :key="`sub-div-${i}`"> diff --git a/app/assets/javascripts/whats_new/components/feature.vue b/app/assets/javascripts/whats_new/components/feature.vue index 32fb2bd34a5..f6f7618b0d8 100644 --- a/app/assets/javascripts/whats_new/components/feature.vue +++ b/app/assets/javascripts/whats_new/components/feature.vue @@ -1,5 +1,5 @@ <script> -import { GlBadge, GlIcon, GlLink } from '@gitlab/ui'; +import { GlBadge, GlIcon, GlLink, GlSafeHtmlDirective } from '@gitlab/ui'; export default { components: { @@ -7,6 +7,9 @@ export default { GlIcon, GlLink, }, + directives: { + SafeHtml: GlSafeHtmlDirective, + }, props: { feature: { type: Object, @@ -51,7 +54,7 @@ export default { class="img-thumbnail gl-px-8 gl-py-3 whats-new-item-image" /> </gl-link> - <p class="gl-pt-3">{{ feature.body }}</p> + <div v-safe-html="feature.body" class="gl-pt-3"></div> <gl-link :href="feature.url" target="_blank" diff --git a/app/assets/stylesheets/pages/groups.scss b/app/assets/stylesheets/pages/groups.scss index 7d870cf5a8b..aeda91c1714 100644 --- a/app/assets/stylesheets/pages/groups.scss +++ b/app/assets/stylesheets/pages/groups.scss @@ -293,12 +293,6 @@ table.pipeline-project-metrics tr td { padding: $gl-padding; } -.mattermost-icon svg { - width: 16px; - height: 16px; - vertical-align: text-bottom; -} - .mattermost-team-name { color: $gl-text-color-secondary; } diff --git a/app/controllers/groups_controller.rb b/app/controllers/groups_controller.rb index 40cb40c9905..068815f7f07 100644 --- a/app/controllers/groups_controller.rb +++ b/app/controllers/groups_controller.rb @@ -69,7 +69,7 @@ class GroupsController < Groups::ApplicationController @group = Groups::CreateService.new(current_user, group_params).execute if @group.persisted? - track_experiment_event(:onboarding_issues, 'created_namespace') + successful_creation_hooks notice = if @group.chat_team.present? "Group '#{@group.name}' and its Mattermost team were successfully created." @@ -319,6 +319,10 @@ class GroupsController < Groups::ApplicationController private + def successful_creation_hooks + track_experiment_event(:onboarding_issues, 'created_namespace') + end + def groups if @group.supports_events? @group.self_and_descendants.public_or_visible_to_user(current_user) diff --git a/app/models/release_highlight.rb b/app/models/release_highlight.rb index 7f8ecae709f..1efba6380e9 100644 --- a/app/models/release_highlight.rb +++ b/app/models/release_highlight.rb @@ -34,11 +34,23 @@ class ReleaseHighlight return if file_path.nil? file = File.read(file_path) - items = YAML.safe_load(file, permitted_classes: [Date]) platform = Gitlab.com? ? 'gitlab-com' : 'self-managed' - items&.select {|item| item[platform] } + + items&.map! do |item| + next unless item[platform] + + begin + item.tap {|i| i['body'] = Kramdown::Document.new(i['body']).to_html } + rescue => e + Gitlab::ErrorTracking.track_exception(e, file_path: file_path) + + next + end + end + + items&.compact rescue Psych::Exception => e Gitlab::ErrorTracking.track_exception(e, file_path: file_path) diff --git a/app/views/groups/_create_chat_team.html.haml b/app/views/groups/_create_chat_team.html.haml index 07394eec107..f141b646e69 100644 --- a/app/views/groups/_create_chat_team.html.haml +++ b/app/views/groups/_create_chat_team.html.haml @@ -1,10 +1,10 @@ .form-group .col-sm-2.col-form-label = f.label :create_chat_team do - %span.mattermost-icon + %span.gl-display-flex = custom_icon('icon_mattermost') - Mattermost - .col-sm-10 + %span.gl-ml-2 Mattermost + .col-sm-12 .form-check.js-toggle-container .js-toggle-button.form-check-input= f.check_box(:create_chat_team, { checked: false }, true, false) = f.label :create_chat_team, class: 'form-check-label' do diff --git a/app/views/groups/_new_group_fields.html.haml b/app/views/groups/_new_group_fields.html.haml index e21a5101ea9..3872bbcd062 100644 --- a/app/views/groups/_new_group_fields.html.haml +++ b/app/views/groups/_new_group_fields.html.haml @@ -2,7 +2,7 @@ = render 'shared/group_form', f: f, autofocus: true .row - .form-group.col-sm-12 + .form-group.col-sm-12.gl-mb-0 %label.label-bold = _('Visibility level') %p @@ -10,8 +10,13 @@ = link_to _('View the documentation'), help_page_path("public_access/public_access"), target: '_blank' = render 'shared/visibility_level', f: f, visibility_level: default_group_visibility, can_change_visibility_level: true, form_model: @group, with_label: false - = render 'create_chat_team', f: f if Gitlab.config.mattermost.enabled - +- if Gitlab.config.mattermost.enabled + .row + = render 'create_chat_team', f: f +.row + .col-sm-4 + = render_if_exists 'shared/groups/invite_members' +.row .form-actions.col-sm-12 = f.submit _('Create group'), class: "btn btn-success" = link_to _('Cancel'), dashboard_groups_path, class: 'btn btn-cancel' diff --git a/app/views/profiles/two_factor_auths/_codes.html.haml b/app/views/profiles/two_factor_auths/_codes.html.haml index 177e6d5453e..178a9d3f8b4 100644 --- a/app/views/profiles/two_factor_auths/_codes.html.haml +++ b/app/views/profiles/two_factor_auths/_codes.html.haml @@ -1,6 +1,6 @@ - show_success_alert = local_assigns.fetch(:show_success_alert, nil) -- if Feature.enabled?(:vue_2fa_recovery_codes, current_user) +- if Feature.enabled?(:vue_2fa_recovery_codes, current_user, default_enabled: true) .js-2fa-recovery-codes{ data: { codes: @codes.to_json, profile_account_path: profile_account_path(two_factor_auth_enabled_successfully: show_success_alert) } } - else %p.slead diff --git a/app/views/profiles/two_factor_auths/create.html.haml b/app/views/profiles/two_factor_auths/create.html.haml index 5895b88df73..be4800024cf 100644 --- a/app/views/profiles/two_factor_auths/create.html.haml +++ b/app/views/profiles/two_factor_auths/create.html.haml @@ -1,7 +1,7 @@ - page_title _('Two-factor Authentication'), _('Account') - add_page_specific_style 'page_bundles/profile_two_factor_auth' -- unless Feature.enabled?(:vue_2fa_recovery_codes, current_user) +- unless Feature.enabled?(:vue_2fa_recovery_codes, current_user, default_enabled: true) .gl-alert.gl-alert-success.gl-mb-5 = _('Congratulations! You have enabled Two-factor Authentication!') diff --git a/app/views/shared/icons/_icon_mattermost.svg b/app/views/shared/icons/_icon_mattermost.svg index d1c541523ab..3cf10851003 100644 --- a/app/views/shared/icons/_icon_mattermost.svg +++ b/app/views/shared/icons/_icon_mattermost.svg @@ -1 +1 @@ -<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 500 500"><path d="M250.05 34c1.9.04 3.8.11 5.6.2l-29.79 35.51c-.07.01-.15.03-.23.04C149.26 84.1 98.22 146.5 98.22 222.97c0 41.56 23.07 90.5 59.75 119.1 28.61 22.32 64.29 36.9 101.21 36.9 93.4 0 160.15-68.61 160.15-156 0-34.91-15.99-72.77-41.76-100.76l-1.63-47.39c54.45 39.15 89.95 103.02 90.06 175.17v.01c0 119.29-96.7 216-216 216-119.29 0-216-96.71-216-216S130.71 34 250 34h.05zm64.1 20.29c.66-.04 1.32.03 1.96.25 3.01 1 3.85 3.57 3.93 6.45l3.84 146.88c.76 28.66-17.16 68.44-60.39 68.56-30.97.08-63.68-20.83-63.68-60.13.01-14.73 5.61-31.26 19.25-48.11l90.03-111.18c1.15-1.42 3.08-2.58 5.06-2.72z"/></svg> +<svg xmlns="http://www.w3.org/2000/svg" width="16" height="16" viewBox="0 0 500 500"><path d="M250.05 34c1.9.04 3.8.11 5.6.2l-29.79 35.51c-.07.01-.15.03-.23.04C149.26 84.1 98.22 146.5 98.22 222.97c0 41.56 23.07 90.5 59.75 119.1 28.61 22.32 64.29 36.9 101.21 36.9 93.4 0 160.15-68.61 160.15-156 0-34.91-15.99-72.77-41.76-100.76l-1.63-47.39c54.45 39.15 89.95 103.02 90.06 175.17v.01c0 119.29-96.7 216-216 216-119.29 0-216-96.71-216-216S130.71 34 250 34h.05zm64.1 20.29c.66-.04 1.32.03 1.96.25 3.01 1 3.85 3.57 3.93 6.45l3.84 146.88c.76 28.66-17.16 68.44-60.39 68.56-30.97.08-63.68-20.83-63.68-60.13.01-14.73 5.61-31.26 19.25-48.11l90.03-111.18c1.15-1.42 3.08-2.58 5.06-2.72z"/></svg> diff --git a/changelogs/unreleased/290113-feature-flag-rollout-of-vue_2fa_recovery_codes.yml b/changelogs/unreleased/290113-feature-flag-rollout-of-vue_2fa_recovery_codes.yml new file mode 100644 index 00000000000..41bf6ebe6ce --- /dev/null +++ b/changelogs/unreleased/290113-feature-flag-rollout-of-vue_2fa_recovery_codes.yml @@ -0,0 +1,5 @@ +--- +title: Require users to copy, download, or print 2FA recovery codes +merge_request: 49493 +author: +type: changed diff --git a/config/feature_flags/development/ci_rules_variables.yml b/config/feature_flags/development/ci_rules_variables.yml new file mode 100644 index 00000000000..fdd9de19472 --- /dev/null +++ b/config/feature_flags/development/ci_rules_variables.yml @@ -0,0 +1,8 @@ +--- +name: ci_rules_variables +introduced_by_url: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/48752 +rollout_issue_url: https://gitlab.com/gitlab-org/gitlab/-/issues/289803 +milestone: '13.7' +type: development +group: group::pipeline authoring +default_enabled: false diff --git a/config/feature_flags/development/vue_2fa_recovery_codes.yml b/config/feature_flags/development/vue_2fa_recovery_codes.yml index 37119bcfe8a..7995b00f9ab 100644 --- a/config/feature_flags/development/vue_2fa_recovery_codes.yml +++ b/config/feature_flags/development/vue_2fa_recovery_codes.yml @@ -5,4 +5,4 @@ rollout_issue_url: https://gitlab.com/gitlab-org/gitlab/-/issues/290113 milestone: '13.7' type: development group: group::access -default_enabled: false +default_enabled: true diff --git a/data/whats_new/202008180001_12_10.yml b/data/whats_new/202008180001_12_10.yml index 66267bfcace..6ffe58e0a62 100644 --- a/data/whats_new/202008180001_12_10.yml +++ b/data/whats_new/202008180001_12_10.yml @@ -1,16 +1,22 @@ --- - title: Create and view requirements in GitLab - body: The first step towards managing requirements from within GitLab is here! This initial release allows users to create and view requirements at a project level. As Requirements Management evolves in GitLab, stay tuned for support for traceability between all artifacts, creating a seamless workflow to visually demonstrate completeness and compliance. + body: | + The first step towards managing requirements from within GitLab is here! This initial release allows users to create and view requirements at a project level. + + As Requirements Management evolves in GitLab, stay tuned for support for traceability between all artifacts, creating a seamless workflow to visually demonstrate completeness and compliance. stage: Plan self-managed: true gitlab-com: true packages: [Ultimate, Gold] url: https://docs.gitlab.com/ee/user/project/requirements/index.html - image_url: + image_url: https://docs.gitlab.com/ee/user/project/requirements/img/requirements_list_v13_5.png published_at: 2020-04-22 release: 12.10 - title: Retrieve CI/CD secrets from HashiCorp Vault - body: In this release, GitLab adds support for lightweight JSON Web Token (JWT) authentication to integrate with your existing HashiCorp Vault. Now, you can seamlessly provide secrets to CI/CD jobs by taking advantage of HashiCorp's JWT authentication method rather than manually having to provide secrets as a variable in GitLab. + body: | + In this release, GitLab adds support for lightweight JSON Web Token (JWT) authentication to integrate with your existing HashiCorp Vault. + + Now, you can seamlessly provide secrets to CI/CD jobs by taking advantage of [HashiCorp's JWT authentication method](https://www.vaultproject.io/docs/auth/jwt) rather than manually having to provide secrets as a variable in GitLab. stage: Release self-managed: true gitlab-com: true @@ -20,7 +26,12 @@ published_at: 2020-04-22 release: 12.10 - title: Epic and Issue Health Tracking - body: To help users track projects and in-flight work GitLab now enables you to report on and quickly respond to the health of individual issues and epics by showing a red, amber, or green health status on your Epic Tree. Assign an issue a health status of On track (green), Needs attention (amber), or At risk (red) and see an aggregate report of health at the Epic level. Quickly view and analyze where a collection of work is at risk so you can open up the right discussions at the right time and keep work on track! + body: | + To help users track projects and in-flight work GitLab now enables you to report on and quickly respond to the health of individual issues and epics by showing a red, amber, or green health status on your Epic Tree. + + Assign an issue a health status of **On track** (green), **Needs attention** (amber), or **At risk** (red) and see an aggregate report of health at the Epic level. + + Quickly view and analyze where a collection of work is at risk so you can open up the right discussions at the right time and keep work on track! stage: Plan self-managed: true gitlab-com: true @@ -30,7 +41,10 @@ published_at: 2020-04-22 release: 12.10 - title: Import Issues from Jira to GitLab - body: Until now, the only way to get Jira issues into GitLab was manually, with our CSV importer, or by hand-rolling your own migration utility. GitLab 12.10 includes an MVC to automatically import your Jira issues into GitLab. This is the first of many planned enhancements to make transitioning from Jira to GitLab as frictionless as possible. + body: | + Until now, the only way to get Jira issues into GitLab was manually, with our CSV importer, or by hand-rolling your own migration utility. + + GitLab 12.10 includes an [MVC](https://about.gitlab.com/handbook/product/product-principles/#the-minimal-viable-change-mvc) to automatically import your Jira issues into GitLab. This is the first of [many planned enhancements](https://gitlab.com/groups/gitlab-org/-/epics/2738) to make transitioning from Jira to GitLab as frictionless as possible. stage: Plan self-managed: true gitlab-com: true @@ -40,7 +54,10 @@ published_at: 2020-04-22 release: 12.10 - title: Autoscaling GitLab CI jobs on AWS Fargate - body: You can now auto-scale GitLab CI on AWS Fargate with the MVC release of GitLab’s AWS Fargate Driver. With this new autoscaling pattern, GitLab’s AWS Fargate driver automatically runs each build in a separate and isolated container on Amazon’s Elastic Container Service (ECS) using a user-defined container image. + body: | + You can now auto-scale GitLab CI on AWS Fargate with the MVC release of GitLab’s AWS Fargate Driver. + + With this new autoscaling pattern, [GitLab’s AWS Fargate driver](https://gitlab.com/gitlab-org/ci-cd/custom-executor-drivers/fargate) automatically runs each build in a separate and isolated container on Amazon’s Elastic Container Service (ECS) using a user-defined container image. stage: Verify self-managed: true gitlab-com: false diff --git a/data/whats_new/202008180002_13_0.yml b/data/whats_new/202008180002_13_0.yml index 3e76baab7f5..c2f86d1ec51 100644 --- a/data/whats_new/202008180002_13_0.yml +++ b/data/whats_new/202008180002_13_0.yml @@ -1,6 +1,9 @@ --- - title: Gitaly Cluster for High Availability Git Storage - body: GitLab now supports highly available Git storage without using NFS. High Availability (HA) configurations improve the availability of important systems, like Git storage, by removing single points of failure, detecting outages, and automatically switching to a replica. This means that an individual component of the system can fail without causing the end user to experience an outage. Access to Git repositories is critical to developers and businesses, because when an outage occurs, developers can’t push code, and deployments are blocked. + body: | + GitLab now supports highly available Git storage without using NFS. High Availability (HA) configurations improve the availability of important systems, like Git storage, by removing single points of failure, detecting outages, and automatically switching to a replica. + + This means that an individual component of the system can fail without causing the end user to experience an outage. Access to Git repositories is critical to developers and businesses, because when an outage occurs, developers can’t push code, and deployments are blocked. stage: Create self-managed: true gitlab-com: false @@ -10,17 +13,23 @@ published_at: 2020-05-22 release: 13.0 - title: Auto Deploy to ECS - body: Until now, there hasn’t been a simple way to deploy to Amazon Web Services. As a result, GitLab users had to spend a lot of time figuring out their own configuration. In GitLab 13.0, Auto DevOps has been extended to support deployment to AWS! GitLab users who are deploying to AWS Elastic Container Service (ECS) can now take advantage of Auto DevOps, even if they are not using Kubernetes. + body: | + Until now, there hasn’t been a simple way to deploy to Amazon Web Services. As a result, GitLab users had to spend a lot of time figuring out their own configuration. + + In GitLab 13.0, Auto DevOps has been extended to support deployment to AWS! GitLab users who are deploying to AWS Elastic Container Service (ECS) can now take advantage of Auto DevOps, even if they are not using Kubernetes. stage: Release self-managed: true gitlab-com: true packages: [All] url: https://docs.gitlab.com/ee/topics/autodevops/index.html#aws-ecs - image_url: + image_url: https://docs.gitlab.com/ee/ci/img/ecs_dashboard_v12_9.png published_at: 2020-05-22 release: 13.0 - title: View Epic Hierarchy on a Roadmap - body: When leveraging Multi-Level Epics, it can be difficult to keep track of where each child epic lives on the Roadmap. You can now quickly expand a parent epic on your roadmap to view all its child epics to ensure work is properly organized and your planned timeline is on track! + body: | + When leveraging Multi-Level Epics, it can be difficult to keep track of where each child epic lives on the Roadmap. + + You can now quickly expand a parent epic on your roadmap to view all its child epics to ensure work is properly organized and your planned timeline is on track! stage: Plan self-managed: true gitlab-com: true @@ -30,7 +39,10 @@ published_at: 2020-05-22 release: 13.0 - title: Versioned Snippets - body: Snippets in GitLab are now version controlled by a Git repository. When editing a Snippet, each change creates a commit. Snippets can also be cloned to make edits locally, and then pushed back to the Snippet repository. + body: | + Snippets in GitLab are now version controlled by a Git repository. When editing a Snippet, each change creates a commit. + + Snippets can also be cloned to make edits locally, and then pushed back to the Snippet repository. stage: Create self-managed: true gitlab-com: true @@ -40,7 +52,10 @@ published_at: 2020-05-22 release: 13.0 - title: Dark Theme in the Web IDE - body: For people who spend time working in code editors, the ability to customize the environment to match their preferences is important. Dark themes are some of the most popular for other editors and important for providing a comfortable experience. That's why we're excited that the GitLab Web IDE is now completely themed dark for users who choose the Dark syntax highlighting theme perference! + body: | + For people who spend time working in code editors, the ability to customize the environment to match their preferences is important. Dark themes are some of the most [popular](https://marketplace.visualstudio.com/search?target=VSCode&category=Themes&sortBy=Installs) for other editors and important for providing a comfortable experience. + + That's why we're excited that the GitLab Web IDE is now completely themed dark for users who choose the **Dark** [syntax highlighting theme perference](https://docs.gitlab.com/ee/user/profile/preferences.html#syntax-highlighting-theme)! stage: Create self-managed: true gitlab-com: true diff --git a/data/whats_new/202008180003_13_01.yml b/data/whats_new/202008180003_13_01.yml index 304f6a29f75..d8bea8ece92 100644 --- a/data/whats_new/202008180003_13_01.yml +++ b/data/whats_new/202008180003_13_01.yml @@ -1,6 +1,9 @@ --- - title: Manage IT Alerts in GitLab - body: GitLab is excited to introduce Alert Management to aggregate multiple IT service alerts in one interface, helping your team triage alerts and promote them to Incidents. We’ve added the ability to triage alerts in a list view, view alert details, assign alerts, update the status of alerts, and create Incident Issues from Alerts. + body: | + GitLab is excited to introduce Alert Management to aggregate multiple IT service alerts in one interface, helping your team triage alerts and promote them to Incidents. + + We’ve added the ability to triage alerts in a [list view](https://gitlab.com/groups/gitlab-org/-/epics/2986), [view alert details](https://gitlab.com/groups/gitlab-org/-/epics/2987), [assign alerts](https://gitlab.com/groups/gitlab-org/-/epics/3349), [update the status of alerts](https://gitlab.com/gitlab-org/gitlab/-/issues/214542), and [create Incident Issues from Alerts](https://gitlab.com/gitlab-org/gitlab/-/issues/213909). stage: Monitor self-managed: true gitlab-com: true @@ -10,7 +13,10 @@ published_at: 2020-06-22 release: 13.1 - title: Accessibility Testing Merge Request Widget - body: Today, developers who want to ensure their application is accessible to everyone suffer from slow feedback loops, which make it difficult to catch degradations in their code. In GitLab 13.1, merge requests can have a widget that details accessibility degradations related to the changed pages. This will immediately show developers the impact of their changes, which helps prevent degradations before they are merged and deployed. + body: | + Today, developers who want to ensure their application is accessible to everyone suffer from slow feedback loops, which make it difficult to catch degradations in their code. + + In GitLab 13.1, merge requests can have a widget that details accessibility degradations related to the changed pages. This will immediately show developers the impact of their changes, which helps prevent degradations before they are merged and deployed. stage: Verify self-managed: true gitlab-com: true @@ -20,7 +26,8 @@ published_at: 2020-06-22 release: 13.1 - title: Mark any Design Thread as Resolved - body: When you receive lots of feedback on a Design, the number of comment pins can build up quickly! As your discussion thread grows, it gets hard to know which discussions are complete and which still need work. Now you’ll have the ability to mark any comment as Resolved to signify that it is now complete. Even better — your resolved comment pins will disappear from the Design so you can focus on what’s left! + body: | + When you receive lots of feedback on a Design, the number of comment pins can build up quickly! As your discussion thread grows, it gets hard to know which discussions are complete and which still need work. Now you’ll have the ability to mark any comment as **Resolved** to signify that it is now complete. Even better — your **Resolved Comment** pins will disappear from the Design so you can focus on what’s left! stage: Create self-managed: true gitlab-com: true @@ -30,7 +37,8 @@ published_at: 2020-06-22 release: 13.1 - title: Merge Request Reviews moved to Core - body: Originally introduced in GitLab 11.4 as a GitLab Premium feature, Merge Request Reviews allow merge request reviewers to submit multiple comments at once, cutting down on notification noise for the merge request author, and allowing for a more cohesive and streamlined review process. + body: | + Originally introduced in GitLab 11.4 as a GitLab Premium feature, Merge Request Reviews allow merge request reviewers to submit multiple comments at once, cutting down on notification noise for the merge request author, and allowing for a more cohesive and streamlined review process. stage: Create self-managed: true gitlab-com: true diff --git a/data/whats_new/202008210001_13_02.yml b/data/whats_new/202008210001_13_02.yml index 77bde327f9c..a9821329cd1 100644 --- a/data/whats_new/202008210001_13_02.yml +++ b/data/whats_new/202008210001_13_02.yml @@ -1,6 +1,9 @@ --- - title: Assign Issues to Iterations - body: Prior to this release, there was no way to associate an issue with more than one timebox in GitLab. This has been particularly problematic for teams that follow Scrum or XP. Such teams often need to associate issues with iterations/sprints, while also rolling that issue up to longer-running milestones, such as program increments. Instead of having to decide whether to use milestones for sprints or program increments and track the other in a spreadsheet, you can now assign issues to iterations, milestones, or both. + body: | + Prior to this release, there was no way to associate an issue with more than one timebox in GitLab. This has been particularly problematic for teams that follow Scrum or XP. Such teams often need to associate issues with iterations/sprints, while also rolling that issue up to longer-running milestones, such as program increments. + + Instead of having to decide whether to use milestones for sprints or program increments and track the other in a spreadsheet, you can now assign issues to iterations, milestones, or both. stage: Plan self-managed: true gitlab-com: true @@ -10,7 +13,10 @@ published_at: 2020-07-22 release: 13.2 - title: Container Host Monitoring and Blocking - body: We’re pleased to announce the first release of Container Host Security. This initial feature, container host monitoring and blocking, allows security administrators to secure their running containers at the host level by monitoring and optionally blocking unexpected activity. Such activity includes process starts, file changes, or opened network ports. This feature uses Falco to provide the monitoring functionality and AppArmor and Pod Security Policies for the blocking functionality. + body: | + We’re pleased to announce the first release of [Container Host Security](https://about.gitlab.com/direction/protect/container_host_security/). This initial feature, container host monitoring and blocking, allows security administrators to secure their running containers at the host level by monitoring and optionally blocking unexpected activity. + + Such activity includes process starts, file changes, or opened network ports. This feature uses [Falco](https://falco.org/) to provide the monitoring functionality and [AppArmor](https://www.kernel.org/doc/html/v4.15/admin-guide/LSM/apparmor.html) and [Pod Security Policies](https://kubernetes.io/docs/concepts/policy/pod-security-policy/) for the blocking functionality. stage: Defend self-managed: true gitlab-com: true @@ -20,7 +26,10 @@ published_at: 2020-07-22 release: 13.2 - title: Official GitLab-Figma Plugin - body: Recently, the GitLab product design team and our open source Pajamas Design System switched over to Figma. We decided to build a new Figma plugin, which allows for easy uploads from Figma to issues on GitLab.com. This makes it quick and easy to collaborate on Designs. Connect your design environment with your source code management in a seamless workflow. + body: | + Recently, the GitLab product design team and our open source [Pajamas Design System](https://design.gitlab.com/) switched over to Figma. We decided to build a new Figma plugin, which allows for easy uploads from Figma to issues on GitLab.com. + + This makes it quick and easy to collaborate on Designs. Connect your design environment with your source code management in a seamless workflow. stage: Create self-managed: false gitlab-com: true @@ -30,7 +39,12 @@ published_at: 2020-07-22 release: 13.2 - title: Cluster health monitoring now available in Core - body: To understand system performance, your development team must monitor the health and performance of the underlying infrastructure. We want our metrics solution to be available to all GitLab users, so as part of our 2020 gift, we’ve moved cluster health in the Monitor stage from GitLab Ultimate to GitLab Core. Beginning with GitLab 13.2, all users can connect a cluster and monitor its health in the GitLab user interface. + body: | + To understand system performance, your development team must monitor the health and performance of the underlying infrastructure. + + We want our metrics solution to be available to all GitLab users, so as part of our [2020 gift](https://about.gitlab.com/blog/2019/12/16/observability/), we’ve moved cluster health in the Monitor stage from GitLab Ultimate to GitLab Core. + + Beginning with GitLab 13.2, all users can connect a cluster and monitor its health in the GitLab user interface. stage: Monitor self-managed: true gitlab-com: true diff --git a/data/whats_new/202009150001_13_03.yml b/data/whats_new/202009150001_13_03.yml index ae22a9826b3..662f6b7e97b 100644 --- a/data/whats_new/202009150001_13_03.yml +++ b/data/whats_new/202009150001_13_03.yml @@ -1,6 +1,9 @@ --- - title: Coverage-guided fuzz testing for Go and C/C++ applications - body: You can now run coverage-guided fuzz tests against your Go and C/C++ apps. This is a great way to start finding security issues and bugs that other security scanners and traditional QA may miss. Coverage-guided fuzz testing uses contextual information about your app to randomly generate inputs and find crashes or other faults that you can then fix before they affect users in production. + body: | + You can now run coverage-guided fuzz tests against your Go and C/C++ apps. This is a great way to start finding security issues and bugs that other security scanners and traditional QA may miss. + + Coverage-guided fuzz testing uses contextual information about your app to randomly generate inputs and find crashes or other faults that you can then fix before they affect users in production. stage: Secure self-managed: true gitlab-com: true @@ -10,7 +13,8 @@ published_at: 2020-08-22 release: 13.3 - title: Create a matrix of jobs using a simple syntax - body: GitLab’s child/parent pipelines let you write your own code to generate an entire pipeline YAML. This is a powerful way to generate custom behaviors, including generating jobs at runtime. This might not be needed for simpler scenarios where you just want to create multiple similar jobs for a defined set of cases. In this release you can find a new matrix keyword that works along with parallel to handle the creation of multiple jobs for you, each with different variables. + body: | + GitLab’s [child/parent pipelines](https://gitlab.com/gitlab-org/gitlab/-/issues/16094) let you write your own code to generate an entire pipeline YAML. This is a powerful way to generate custom behaviors, including generating jobs at runtime. This might not be needed for simpler scenarios where you just want to create multiple similar jobs for a defined set of cases. In this release you can find a new `matrix` keyword that works along with `parallel` to handle the creation of multiple jobs for you, each with different variables. stage: Verify self-managed: true gitlab-com: true @@ -20,7 +24,12 @@ published_at: 2020-08-22 release: 13.3 - title: On-demand DAST scans - body: Dynamic Application Security Testing at GitLab has always been focused on integrating DAST into the DevOps pipeline and enabling developers to scan their review app, running website, or API for vulnerabilities as early as possible. However, there are times when it is necessary to run a DAST scan against an already deployed application when no code changes have been made and no Merge Request has been created. These scans could be needed for audit or compliance reasons, to debug and reproduce an issue that has been found, or to support teams who do not commit code, such as security analysts. Because of the need for DAST scans that are not triggered by a code change or MR, on-demand DAST testing is now available. You don’t need configuration files or code to start running on-demand scans. Configuration options for on-demand DAST scans are available within the GitLab UI. + body: | + Dynamic Application Security Testing at GitLab has always been focused on integrating DAST into the DevOps pipeline and enabling developers to scan their review app, running website, or API for vulnerabilities as early as possible. + + However, there are times when it is necessary to run a DAST scan against an already deployed application when no code changes have been made and no Merge Request has been created. These scans could be needed for audit or compliance reasons, to debug and reproduce an issue that has been found, or to support teams who do not commit code, such as security analysts. + + Because of the need for DAST scans that are not triggered by a code change or MR, on-demand DAST testing is now available. You don’t need configuration files or code to start running on-demand scans. Configuration options for on-demand DAST scans are available within the GitLab UI. stage: Secure self-managed: true gitlab-com: true @@ -30,7 +39,10 @@ published_at: 2020-08-22 release: 13.3 - title: SAST security analyzers available for all - body: We want to help developers write better code and worry less about common security mistakes. Static Application Security Testing (SAST) helps prevent security vulnerabilities by allowing developers to easily identify common security issues as code is being committed and mitigate proactively. As part of our community stewardship commitment we have made all 15 of our open source based SAST analyzers available in every GitLab tier. This allows ALL GitLab users developing in any of our 18 supported languages and frameworks to leverage GitLab SAST in their projects. + body: | + We want to help developers write better code and worry less about common security mistakes. [Static Application Security Testing (SAST)](https://docs.gitlab.com/ee/user/application_security/sast/) helps prevent security vulnerabilities by allowing developers to easily identify common security issues as code is being committed and mitigate proactively. + + As part of our [community stewardship commitment](https://about.gitlab.com/company/stewardship/#promises) we have made [all 15 of our open source based SAST analyzers](https://docs.gitlab.com/ee/user/application_security/sast/#supported-languages-and-frameworks) available in every GitLab tier. This allows ALL GitLab users developing in any of our [18 supported languages and frameworks](https://docs.gitlab.com/ee/user/application_security/sast/#supported-languages-and-frameworks) to leverage GitLab SAST in their projects. stage: Secure self-managed: true gitlab-com: true diff --git a/data/whats_new/202009300001_13_04.yml b/data/whats_new/202009300001_13_04.yml index 0e54a137bae..c4457303479 100644 --- a/data/whats_new/202009300001_13_04.yml +++ b/data/whats_new/202009300001_13_04.yml @@ -1,6 +1,7 @@ --- - title: Use HashiCorp Vault secrets in CI jobs - body: In GitLab 12.10, GitLab introduced functionality for GitLab Runner to fetch and inject secrets into CI jobs. GitLab is now expanding the JWT Vault Authentication method by building a new secrets syntax in the .gitlab-ci.yml file. This makes it easier for you to configure and use HashiCorp Vault with GitLab. + body: | + In GitLab 12.10, GitLab introduced functionality for GitLab Runner to fetch and inject secrets into CI jobs. GitLab is now expanding the [JWT Vault Authentication method](https://docs.gitlab.com/ee/ci/examples/authenticating-with-hashicorp-vault/) by building a new `secrets` syntax in the `.gitlab-ci.yml` file. This makes it easier for you to configure and use HashiCorp Vault with GitLab. stage: Release self-managed: true gitlab-com: true @@ -10,7 +11,14 @@ published_at: 2020-09-22 release: 13.4 - title: Introducing the GitLab Kubernetes Agent - body: "GitLab's Kubernetes integration has long enabled deployment to Kubernetes clusters without manual setup. Many users have enjoyed the ease-of-use, while others have run into some challenges. The current integration requires your cluster to be open to the Internet for GitLab to access it. For many organizations, this isn't possible, because they must lock down their cluster access for security, compliance, or regulatory purposes. To work around these restrictions, users needed to create custom tooling on top of GitLab, or they couldn't use the feature. Today, we're announcing the GitLab Kubernetes Agent: a new way to deploy to Kubernetes clusters. The Agent runs inside of your cluster, so you don't need to open it to the internet. The Agent orchestrates deployments by pulling new changes from GitLab, rather than GitLab pushing updates to the cluster. No matter what method of GitOps you use, GitLab has you covered." + body: | + GitLab's Kubernetes integration has long enabled deployment to Kubernetes clusters without manual setup. Many users have enjoyed the ease-of-use, while others have run into some challenges. The current integration requires your cluster to be open to the Internet for GitLab to access it. + + For many organizations, this isn't possible, because they must lock down their cluster access for security, compliance, or regulatory purposes. To work around these restrictions, users needed to create custom tooling on top of GitLab, or they couldn't use the feature. + + Today, we're announcing the GitLab Kubernetes Agent: a new way to deploy to Kubernetes clusters. The Agent runs inside of your cluster, so you don't need to open it to the internet. The Agent orchestrates deployments by pulling new changes from GitLab, rather than GitLab pushing updates to the cluster. + + No matter what method of GitOps you use, GitLab has you covered. stage: Configure self-managed: true gitlab-com: false @@ -20,7 +28,10 @@ published_at: 2020-09-22 release: 13.4 - title: Grant users deployment permissions without code access - body: If your team needs to maintain separation of duties between team members who own development, and team members who own deployments, the permissions paradigm in GitLab has made this challenging. In GitLab 13.4, you can give non-code contributors permission to approve merge requests for deployment, and actually deploy code, without also granting them maintainer access. + body: | + If your team needs to maintain separation of duties between team members who own development, and team members who own deployments, the permissions paradigm in GitLab has made this challenging. + + In GitLab 13.4, you can give non-code contributors permission to approve merge requests for deployment, and actually deploy code, without also granting them maintainer access. stage: Release self-managed: true gitlab-com: true @@ -30,7 +41,12 @@ published_at: 2020-09-22 release: 13.4 - title: Security Center - body: We've made a foundational change to security visibility and management in GitLab. The Instance Security Dashboard has been transformed into a Security Center. The biggest change is introducing a new menu structure. Rather than a single page, you can now find a Security Dashboard, Vulnerability Report, and Settings area. While the functionality hasn't changed, breaking things apart enables future enhancements that would have been difficult otherwise. This also creates a top-level framework for including other security-related functionality in the future. The dedicated Vulnerability Report now has more room to display important details and inherits those currently found on the Project vulnerability list. Separating the vulnerability metrics widgets into their own area creates a true Security Dashboard. + body: | + We've made a foundational change to security visibility and management in GitLab. The Instance Security Dashboard has been transformed into a Security Center. The biggest change is introducing a new menu structure. Rather than a single page, you can now find a Security Dashboard, Vulnerability Report, and Settings area. + + While the functionality hasn't changed, breaking things apart enables future enhancements that would have been difficult otherwise. This also creates a top-level framework for including other security-related functionality in the future. + + The dedicated Vulnerability Report now has more room to display important details and inherits those currently found on the Project vulnerability list. Separating the vulnerability metrics widgets into their own area creates a true Security Dashboard. stage: Secure self-managed: true gitlab-com: true @@ -40,7 +56,10 @@ published_at: 2020-09-22 release: 13.4 - title: Feature Flags made available in GitLab Starter - body: Earlier this year, GitLab committed to moving 18 features to our open source core product. With this release of GitLab we've finished moving Feature Flags to Starter, and we are continuing to migrate our Feature Flag service to Core in GitLab 13.5. We're excited about bringing these features to more users and seeing what use cases and workflows you use them for. + body: | + Earlier this year, GitLab committed to [moving 18 features](https://about.gitlab.com/blog/2020/03/30/new-features-to-core/) to our open source core product. With this release of GitLab we've finished moving Feature Flags to Starter, and we are continuing to migrate our Feature Flag service to Core in [GitLab 13.5](https://gitlab.com/gitlab-org/gitlab/-/issues/212318). + + We're excited about bringing these features to more users and seeing what use cases and workflows you use them for. stage: Release self-managed: true gitlab-com: true @@ -50,7 +69,10 @@ published_at: 2020-09-22 release: 13.4 - title: Quick navigation using the Search bar - body: When navigating through GitLab, sometimes you just want to go to a specific project and not a search result page. Using the Global search bar, you can now quickly jump to recent issues, groups, projects, settings, and help topics. You can even use the `/` keyboard shortcut to move the cursor to the search bar, to navigate GitLab even more efficiently! + body: | + When navigating through GitLab, sometimes you just want to go to a specific project and not a search result page. Using the Global search bar, you can now quickly jump to recent issues, groups, projects, settings, and help topics. + + You can even use the `/` keyboard shortcut to move the cursor to the search bar, to navigate GitLab even more efficiently! stage: Enablement self-managed: true gitlab-com: true diff --git a/data/whats_new/202010230001_13_05.yml b/data/whats_new/202010230001_13_05.yml index 1c6249ae477..4c80af05359 100644 --- a/data/whats_new/202010230001_13_05.yml +++ b/data/whats_new/202010230001_13_05.yml @@ -1,6 +1,13 @@ --- - title: Group wikis - body: For many teams, using GitLab wikis for planning and documentation is a critical part of their workflow. Wikis are so popular that they get over a million views each month on GitLab.com. Despite this popularity, teams have struggled with the limitation that wikis were only available at the project level. Teams working on multiple projects needed to create separate wikis for each repository, leading to a fragmented experience. In Gitlab 13.5, we are so excited to bring you group wikis! This was the most upvoted feature in the entire GitLab backlog. While highly requested, making a large project-only feature like wikis available at the group level has been a non-trivial operation. We’ve worked tirelessly over the past year to make it happen and now we can't wait to get it in your hands and hear your feedback. + body: | + For many teams, using GitLab wikis for planning and documentation is a critical part of their workflow. Wikis are so popular that they get over a million views each month on GitLab.com. + + Despite this popularity, teams have struggled with the limitation that wikis were only available at the project level. Teams working on multiple projects needed to create separate wikis for each repository, leading to a fragmented experience. + + In Gitlab 13.5, we are so excited to bring you group wikis! With [680 upvotes](https://gitlab.com/gitlab-org/gitlab/-/issues/13195) this was the most upvoted feature in the entire GitLab backlog. While highly requested, making a large project-only feature like wikis available at the group level has been a non-trivial operation. + + We know a lot of folks have been looking forward to this feature and shared their input pre-release. We hope all of you will continue to weigh in now that group wikis are available and we’ve opened up a [dedicated issue](https://gitlab.com/gitlab-org/gitlab/-/issues/267593) for your feedback. stage: Create self-managed: true gitlab-com: true @@ -10,7 +17,10 @@ published_at: 2020-10-22 release: 13.5 - title: Install the GitLab Kubernetes Agent with Omnibus GitLab - body: "Last month we introduced the GitLab Kubernetes Agent for self-managed GitLab instances installed with Helm. This release adds support for the official Linux package. In this new Kubernetes integration, the Agent orchestrates deployments by pulling new changes from GitLab, rather than GitLab pushing updates to your cluster." + body: | + Last month we introduced the [GitLab Kubernetes Agent](https://about.gitlab.com/releases/2020/09/22/gitlab-13-4-released/#introducing-the-gitlab-kubernetes-agent) for self-managed GitLab instances installed with Helm. + + This release adds support for the [official Linux package](https://about.gitlab.com/install/). In this new Kubernetes integration, the Agent orchestrates deployments by pulling new changes from GitLab, rather than GitLab pushing updates to your cluster. You can learn more about [how the Kubernetes Agent works now](https://docs.gitlab.com/ee/user/clusters/agent/) and [check out our vision](https://about.gitlab.com/direction/configure/kubernetes_management/) to see what’s in store. stage: Configure self-managed: true gitlab-com: false @@ -20,7 +30,12 @@ published_at: 2020-10-22 release: 13.5 - title: Snippets with multiple files - body: Engineers often use Snippets to share examples of code, reusable components, logs, and other items. These valuable pieces of information often require additional context and may require more than one file. Sharing a link to multiple files or multiple Snippets makes it challenging for users to piece this context together and understand the scope of what is being presented. GitLab now supports multiple files inside of a single Snippet, so you can create Snippets composed of multiple parts. It broadens its use to endless possibilities! + body: | + Engineers often use Snippets to share examples of code, reusable components, logs, and other items. These valuable pieces of information often require additional context and may require more than one file. Sharing a link to multiple files or multiple Snippets makes it challenging for users to piece this context together and understand the scope of what is being presented. + + In GitLab 13.0, we laid a foundation for Snippets by giving them [version control](https://about.gitlab.com/releases/2020/05/22/gitlab-13-0-released/#versioned-snippets) support based on a Git repository. Version control and the history it provides are an important piece of context when looking at code and understanding its purpose, but it may not be everything. + + GitLab now supports multiple files inside of a single Snippet, so you can create Snippets composed of multiple parts. It broadens its use to endless possibilities! stage: Create self-managed: true gitlab-com: true @@ -30,7 +45,10 @@ published_at: 2020-10-22 release: 13.5 - title: Enable instance-level shared runners when viewing groups - body: GitLab SaaS includes Linux and Windows runners, which are easy to use agents that run your GitLab CI/CD pipeline jobs. These runners, visible in the GitLab.com UI as "shared runners," are enabled by default and can be disabled for each project. However, some organizations require their CI/CD jobs to run only on self-managed runners, and so disabling the use of instance-level shared runners on each project resulted in unnecessary administrative overhead. Now administrators can enable or disable shared runners at the group level. Administrators can also allow groups to override the global setting and use shared runners on a project-by-project basis. + body: | + GitLab SaaS includes Linux and Windows runners, which are easy to use agents that run your GitLab CI/CD pipeline jobs. These runners, visible in the GitLab.com UI as "shared runners," are enabled by default and can be disabled for each project. However, some organizations require their CI/CD jobs to run only on self-managed runners, and so disabling the use of instance-level shared runners on each project resulted in unnecessary administrative overhead. + + Now administrators can enable or disable shared runners at the group level. Administrators can also allow groups to override the global setting and use shared runners on a project-by-project basis. stage: Verify self-managed: true gitlab-com: true @@ -40,7 +58,10 @@ published_at: 2020-10-22 release: 13.5 - title: Feature Flags flexible rollout strategy - body: When you use the percent rollout strategy today, the stickiness, or the experience consistency, is determined only by the user ID. This can be limiting; as an example, anonymous users cannot be affected by this strategy. We have improved this rollout strategy by enabling you to define the stickiness based on session ID, user ID, or at random (no stickiness). This gives you more control over the rollout and allows you to support stickiness for anonymous users. + body: | + When you use the `percent rollout` strategy today, the stickiness, or the experience consistency, is determined only by the user ID. This can be limiting; as an example, anonymous users cannot be affected by this strategy. + + We have improved this rollout strategy by enabling you to define the stickiness based on session ID, user ID, or at random (no stickiness). This gives you more control over the rollout and allows you to support stickiness for anonymous users. stage: Release self-managed: true gitlab-com: true @@ -50,7 +71,10 @@ published_at: 2020-10-22 release: 13.5 - title: SAST support for iOS and Android mobile apps - body: GitLab SAST now supports mobile applications including iOS apps written in Objective-C and Swift as well as Android apps written in Java and Kotlin powered by the Mobile Security Framework (MobSF). Initially this analyzer supports source code analysis but we intend to expand support for binary scanning of .ipa and .apk files in the near future. This feature was a generous contribution by the H-E-B Digital team. + body: | + GitLab [SAST](https://docs.gitlab.com/ee/user/application_security/sast/) now supports mobile applications including iOS apps written in Objective-C and Swift as well as Android apps written in Java and Kotlin powered by the [Mobile Security Framework (MobSF)](https://github.com/MobSF/Mobile-Security-Framework-MobSF). Initially this analyzer supports source code analysis but we [intend to expand support for binary scanning](https://gitlab.com/gitlab-org/gitlab/-/issues/269915) of `.ipa` and `.apk` files in the near future. + + This feature was a generous contribution by the [H-E-B Digital](https://digital.heb.com/) team. stage: Secure self-managed: true gitlab-com: true diff --git a/data/whats_new/202011230001_13_06.yml b/data/whats_new/202011230001_13_06.yml index faa4cf62ea9..d4dd958192f 100644 --- a/data/whats_new/202011230001_13_06.yml +++ b/data/whats_new/202011230001_13_06.yml @@ -1,6 +1,11 @@ --- - title: Auto Deploy to EC2 - body: Auto DevOps has been expanded to support deployments to Amazon Web Services. You can now deploy to AWS Cloud Compute (EC2) and take advantage of Auto DevOps, even without Kubernetes. To enable this workflow, you must enable Auto DevOps and define the AWS-typed environment variables AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, and AWS_DEFAULT_REGION. This allows you to provision your own infrastructure by leveraging the AWS CloudFormation API. Then, you can push your previously built artifact to an AWS S3 bucket, and deploy the content to an AWS EC2 instance. Your EC2 deployment then automatically builds you a complete, automatic delivery pipeline without extra manual steps. + body: | + Auto DevOps has been expanded to support deployments to Amazon Web Services. You can now deploy to AWS Cloud Compute (EC2) and take advantage of Auto DevOps, even without Kubernetes. + + To enable this workflow, you must enable Auto DevOps and define the AWS-typed environment variables `AWS_ACCESS_KEY_ID`, `AWS_SECRET_ACCESS_KEY`, and `AWS_DEFAULT_REGION`. This allows you to provision your own infrastructure by leveraging the [AWS CloudFormation API](https://aws.amazon.com/cloudformation/). + + Then, you can push your previously built artifact to an [AWS S3 bucket](https://aws.amazon.com/s3/), and deploy the content to an [AWS EC2](https://aws.amazon.com/ec2/?ec2-whats-new.sort-by=item.additionalFields.postDateTime&ec2-whats-new.sort-order=desc) instance. Your EC2 deployment then automatically builds you a complete, automatic delivery pipeline without extra manual steps. stage: Release self-managed: true gitlab-com: true @@ -10,7 +15,10 @@ published_at: 2020-11-22 release: 13.6 - title: Display Code Quality severity ratings - body: The Code Quality feature in GitLab is great at showing what quality violations exist in a project or are changing in the Merge Request. However, understanding which of those violations is the most important is not clear in the GitLab interface today. With the Full Code Quality Report and Merge Request Widget, now you can see the severity rating. This makes it easy for you to understand which code quality violations are most important to resolve before merging and reduces the technical debt in your project. + body: | + The Code Quality feature in GitLab is great at showing what quality violations exist in a project or are changing in the Merge Request. However, understanding which of those violations is the most important is not clear in the GitLab interface today. + + With the Full Code Quality Report and Merge Request Widget, now you can see the severity rating. This makes it easy for you to understand which code quality violations are most important to resolve before merging and reduces the technical debt in your project. stage: Verify self-managed: true gitlab-com: true @@ -20,7 +28,14 @@ published_at: 2020-11-22 release: 13.6 - title: Display code coverage data for selected projects - body: In 13.4, we released the first iteration of Code Coverage data for Groups that enables you to compare the coverage of multiple projects and download the data in a single file from a single screen. However, to analyze the data, you had to open the file to check it manually, and probably imported it into a spreadsheet for further analysis. In GitLab 13.6, you can now select specific projects in a group to see their latest coverage values directly in GitLab itself without needing to download a file or waste development time accessing code coverage data. + body: | + In 13.4, we released the first iteration of [Code Coverage data for Groups](https://about.gitlab.com/releases/2020/09/22/gitlab-13-4-released/#code-coverage-data-for-all-projects-in-a-group) that enables you to compare the coverage of multiple projects and download the data in a single file from a single screen. + + However, to analyze the data, you had to open the file to check it manually, and probably imported it into a spreadsheet for further analysis. + + In GitLab 13.6, you can now select specific projects in a group to see their latest coverage values directly in GitLab itself without needing to download a file or waste development time accessing code coverage data. + + We welcome feedback on the functionality and possible iterations for this feature in our [feedback issue](https://gitlab.com/gitlab-org/gitlab/-/issues/231515). stage: Verify self-managed: true gitlab-com: true @@ -30,7 +45,16 @@ published_at: 2020-11-22 release: 13.6 - title: Group-level management of project integrations - body: In GitLab 13.3, we added the ability to enable an integration across an entire instance. With GitLab 13.6, that feature is being expanded to allow integrations to be managed at the group level as well! Group owners can now add an integration to a group, and that integration will be inherited by all projects under that group. This has the potential for saving massive amounts of time, as many organizations have specific integrations that they want rolled out to every project they create. A great example of this is using our Jira integration. If you're using Jira, it's almost always across the whole company. Some of these companies have _thousands of projects_ and therefore had to configure each and every one of those integrations individually.With group-level management of project integrations, you can add the integration at each parent group, reducing the amount of configuration required by orders of magnitude! + body: | + In GitLab 13.3, we added the ability to [enable an integration across an entire instance](https://about.gitlab.com/releases/2020/08/22/gitlab-13-3-released/#instance-level-project-integration-management-for-external-services). With GitLab 13.6, that feature is being expanded to allow integrations to be managed at the group level as well! Group owners can now add an integration to a group, and that integration will be inherited by all projects under that group. + + This has the potential for saving massive amounts of time, as many organizations have specific integrations that they want rolled out to every project they create. + + A great example of this is using our [Jira integration](https://docs.gitlab.com/ee/user/project/integrations/jira.html). If you're using Jira, it's almost always across the whole company. Some of these companies have _thousands of projects_ and therefore had to configure each and every one of those integrations individually. + + With group-level management of project integrations, you can add the integration at each parent group, reducing the amount of configuration required by orders of magnitude! + + Read more in [our announcement on the GitLab blog](https://about.gitlab.com/blog/2020/11/19/integration-management/). stage: Create self-managed: true gitlab-com: true @@ -40,7 +64,14 @@ published_at: 2020-11-22 release: 13.6 - title: Milestone Burnup Charts and historically accurate reporting - body: A milestone or iteration burndown chart helps track completion progress of total scope, but it doesn't provide insight into how the scope changed during the course of the timebox. Neither has it previously retained historical accuracy regarding how much of the initial committed scope of the milestone or iteration was actually completed. To solve these problems and help teams have better insights into scope creep, milestones and iterations now show a burnup chart that tracks the daily total count and weight of issues added to and completed within a given timebox. This change only applies to milestones and iterations created in GitLab 13.6 or later. Milestones created prior to 13.6 will still have access to legacy burndown charts. + body: | + A milestone or iteration burndown chart helps track completion progress of total scope, but it doesn't provide insight into how the scope changed during the course of the timebox. Neither has it previously retained historical accuracy regarding how much of the initial committed scope of the milestone or iteration was actually completed. + + To solve these problems and help teams have better insights into scope creep, milestones and iterations now show a burnup chart that tracks the daily total count and weight of issues added to and completed within a given timebox. + + We also refactored burndown charts to use immutable [resource state events](https://docs.gitlab.com/ee/api/resource_state_events.html#issues) that ensure that milestone and iteration charts remain historically accurate even after you’ve moved issues to another timebox. + + This change only applies to milestones and iterations created in GitLab 13.6 or later. Milestones created prior to 13.6 will still have access to [legacy burndown charts](https://docs.gitlab.com/ee/user/project/milestones/burndown_and_burnup_charts.html#fixed-burndown-charts). stage: Plan self-managed: true gitlab-com: true diff --git a/doc/api/vulnerability_findings.md b/doc/api/vulnerability_findings.md index 302032f787f..95e4774ae96 100644 --- a/doc/api/vulnerability_findings.md +++ b/doc/api/vulnerability_findings.md @@ -99,6 +99,7 @@ Example response: } ], "project_fingerprint": "fa6f5b6c5d240b834ac5e901dc69f9484cef89ec", + "uuid": "31f483bc-bfc0-586d-9b92-f1015c4535b8", "create_vulnerability_feedback_issue_path": "/tests/yarn-remediation-test/vulnerability_feedback", "create_vulnerability_feedback_merge_request_path": "/tests/yarn-remediation-test/vulnerability_feedback", "create_vulnerability_feedback_dismissal_path": "/tests/yarn-remediation-test/vulnerability_feedback", diff --git a/doc/ci/yaml/README.md b/doc/ci/yaml/README.md index 226d1f680f4..7ca74cdf2a2 100644 --- a/doc/ci/yaml/README.md +++ b/doc/ci/yaml/README.md @@ -989,6 +989,7 @@ The job attributes you can use with `rules` are: - [`when`](#when): If not defined, defaults to `when: on_success`. - If used as `when: delayed`, `start_in` is also required. - [`allow_failure`](#allow_failure): If not defined, defaults to `allow_failure: false`. +- [`variables`](#rulesvariables): If not defined, uses the [variables defined elsewhere](#variables). If a rule evaluates to true, and `when` has any value except `never`, the job is included in the pipeline. @@ -1410,6 +1411,56 @@ job: In this example, if the first rule matches, then the job has `when: manual` and `allow_failure: true`. +#### `rules:variables` + +> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/209864) in GitLab 13.7. +> - It's [deployed behind a feature flag](../../user/feature_flags.md), disabled by default. +> - It's disabled on GitLab.com. +> - It's not recommended for production use. +> - To use it in GitLab self-managed instances, ask a GitLab administrator to [enable it](#enable-or-disable-rulesvariables). **(CORE ONLY)** + +WARNING: +This feature might not be available to you. Check the **version history** note above for details. + +You can use [`variables`](#variables) in `rules:` to define variables for specific conditions. + +For example: + +```yaml +job: + variables: + DEPLOY_VARIABLE: "default-deploy" + rules: + - if: $CI_COMMIT_REF_NAME =~ /master/ + variables: # Override DEPLOY_VARIABLE defined + DEPLOY_VARIABLE: "deploy-production" # at the job level. + - if: $CI_COMMIT_REF_NAME =~ /feature/ + variables: + IS_A_FEATURE: "true" # Define a new variable. + script: + - echo "Run script with $DEPLOY_VARIABLE as an argument" + - echo "Run another script if $IS_A_FEATURE exists" +``` + +##### Enable or disable rules:variables **(CORE ONLY)** + +rules:variables is under development and not ready for production use. It is +deployed behind a feature flag that is **disabled by default**. +[GitLab administrators with access to the GitLab Rails console](../../administration/feature_flags.md) +can enable it. + +To enable it: + +```ruby +Feature.enable(:ci_rules_variables) +``` + +To disable it: + +```ruby +Feature.disable(:ci_rules_variables) +``` + #### Complex rule clauses To conjoin `if`, `changes`, and `exists` clauses with an `AND`, use them in the diff --git a/doc/user/gitlab_com/index.md b/doc/user/gitlab_com/index.md index 9a861cef3d3..9a9bb6038f4 100644 --- a/doc/user/gitlab_com/index.md +++ b/doc/user/gitlab_com/index.md @@ -611,6 +611,13 @@ dropped and users get To help avoid abuse, project and group imports, exports, and export downloads are rate limited. See [Project import/export rate limits](../../user/project/settings/import_export.md#rate-limits) and [Group import/export rate limits](../../user/group/settings/import_export.md#rate-limits) for details. +GitLab.com Import/Export Rate Limits are set to the default except: + +| Setting | GitLab.com | Default | +|:-------------------------------------------------|:-----------|:--------| +| Max Project Export requests per minute per user | 1 | 6 | +| Max Group Export requests per minute per user | 1 | 6 | + ### Non-configurable limits See [non-configurable limits](../../security/rate_limits.md#non-configurable-limits) for information on diff --git a/doc/user/group/settings/import_export.md b/doc/user/group/settings/import_export.md index fc0f0f16ded..2aee8706194 100644 --- a/doc/user/group/settings/import_export.md +++ b/doc/user/group/settings/import_export.md @@ -121,10 +121,12 @@ For example: ## Rate Limits -To help avoid abuse, users are rate limited to: +To help avoid abuse, by default, users are rate limited to: | Request Type | Limit | | ---------------- | ---------------------------------------- | -| Export | 30 groups every 5 minutes | -| Download export | 10 downloads per group every 10 minutes | -| Import | 30 groups every 5 minutes | +| Export | 6 groups per minute | +| Download export | 1 download per group per minute | +| Import | 6 groups per minute | + +Please note that GitLab.com may have [different settings](../../gitlab_com/index.md#importexport) from the defaults. diff --git a/doc/user/project/canary_deployments.md b/doc/user/project/canary_deployments.md index f3bb12c8a63..52c825932fa 100644 --- a/doc/user/project/canary_deployments.md +++ b/doc/user/project/canary_deployments.md @@ -103,21 +103,22 @@ Here's an example setup flow from scratch: #### How to check the current traffic weight on a Canary Ingress -1. Visit [Deploy Board](../../user/project/deploy_boards.md). -1. Open your browser's inspection tool and examine a response from the `environments.json` endpoint. - You can find the current weight under `rollout_status`. +1. Visit the [Deploy Board](../../user/project/deploy_boards.md). +1. View the current weights on the right. -  - - Note that we have [a plan](https://gitlab.com/gitlab-org/gitlab/-/issues/218139) - to visualize this information in a [Deploy Board](../../user/project/deploy_boards.md) - without needing a browser's inspection tool. +  #### How to change the traffic weight on a Canary Ingress -You can change the traffic weight by using [GraphiQL](../../api/graphql/getting_started.md#graphiql) +You can change the traffic weight within your environment's Deploy Board by using [GraphiQL](../../api/graphql/getting_started.md#graphiql), or by sending requests to the [GraphQL API](../../api/graphql/getting_started.md#command-line). +To use your [Deploy Board](../../user/project/deploy_boards.md): + +1. Navigate to **Operations > Environments** for your project. +1. Set the new weight with the dropdown on the right side. +1. Confirm your selection. + Here's an example using [GraphiQL](../../api/graphql/getting_started.md#graphiql): 1. Visit [GraphiQL Explorer](https://gitlab.com/-/graphql-explorer). @@ -136,6 +137,3 @@ Here's an example using [GraphiQL](../../api/graphql/getting_started.md#graphiql 1. If the request succeeds, the `errors` response contains an empty array. GitLab sends a `PATCH` request to your Kubernetes cluster for updating the weight parameter on a Canary Ingress. - -Note that there's [a plan](https://gitlab.com/gitlab-org/gitlab/-/issues/218139) -to control the weight from a [Deploy Board](../../user/project/deploy_boards.md). diff --git a/doc/user/project/clusters/serverless/index.md b/doc/user/project/clusters/serverless/index.md index d87523089b5..fcbf85121b2 100644 --- a/doc/user/project/clusters/serverless/index.md +++ b/doc/user/project/clusters/serverless/index.md @@ -450,7 +450,6 @@ To run a function locally: > Introduced in GitLab 11.5. -12345678901234567890123456789012345678901234567890123456789012345678901234567890 Serverless applications are an alternative to [serverless functions](#deploying-functions). They're useful in scenarios where an existing runtime does not meet the needs of an application, such as one written in a language that has no runtime available. diff --git a/doc/user/project/img/canary_weight.png b/doc/user/project/img/canary_weight.png Binary files differnew file mode 100644 index 00000000000..e6544358c15 --- /dev/null +++ b/doc/user/project/img/canary_weight.png diff --git a/doc/user/project/img/rollout_status_canary_ingress.png b/doc/user/project/img/rollout_status_canary_ingress.png Binary files differdeleted file mode 100644 index fb59ba31615..00000000000 --- a/doc/user/project/img/rollout_status_canary_ingress.png +++ /dev/null diff --git a/doc/user/project/settings/import_export.md b/doc/user/project/settings/import_export.md index ec4835b7e6a..53233cc347e 100644 --- a/doc/user/project/settings/import_export.md +++ b/doc/user/project/settings/import_export.md @@ -191,12 +191,14 @@ As described in the API documentation, the query may return an import error or e If you have a larger project, consider using a Rake task, as described in our [developer documentation](../../../development/import_project.md#importing-via-a-rake-task). -## Rate limits +## Rate Limits -To help avoid abuse, users are rate limited to: +To help avoid abuse, by default, users are rate limited to: -| Request Type | Limit | -| ---------------- | ----------------------------------------- | -| Export | 30 projects per 5 minutes | -| Download export | 10 downloads per project every 10 minutes | -| Import | 30 projects per 5 minutes | +| Request Type | Limit | +| ---------------- | ---------------------------------------- | +| Export | 6 projects per minute | +| Download export | 1 download per group per minute | +| Import | 6 projects per minute | + +Please note that GitLab.com may have [different settings](../../gitlab_com/index.md#importexport) from the defaults. diff --git a/doc/user/project/settings/project_access_tokens.md b/doc/user/project/settings/project_access_tokens.md index cb5ff27da96..494f0b725e3 100644 --- a/doc/user/project/settings/project_access_tokens.md +++ b/doc/user/project/settings/project_access_tokens.md @@ -8,7 +8,7 @@ type: reference, howto # Project access tokens NOTE: -Project access tokens are supported for self-managed instances on Core and above. They are also supported on GitLab.com Bronze and above. +Project access tokens are supported for self-managed instances on Core and above. They are also supported on GitLab.com Bronze and above (excluding [trial licenses](https://about.gitlab.com/free-trial/)). > - [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/2587) in GitLab 13.0. > - It was [deployed](https://gitlab.com/groups/gitlab-org/-/epics/2587) behind a feature flag, disabled by default. diff --git a/lib/gitlab/ci/build/rules.rb b/lib/gitlab/ci/build/rules.rb index a500a0cc35d..a39afee194c 100644 --- a/lib/gitlab/ci/build/rules.rb +++ b/lib/gitlab/ci/build/rules.rb @@ -6,18 +6,31 @@ module Gitlab class Rules include ::Gitlab::Utils::StrongMemoize - Result = Struct.new(:when, :start_in, :allow_failure) do - def build_attributes + Result = Struct.new(:when, :start_in, :allow_failure, :variables) do + def build_attributes(seed_attributes = {}) { when: self.when, options: { start_in: start_in }.compact, - allow_failure: allow_failure + allow_failure: allow_failure, + yaml_variables: yaml_variables(seed_attributes[:yaml_variables]) }.compact end def pass? self.when != 'never' end + + private + + def yaml_variables(seed_variables) + return unless variables && seed_variables + + indexed_seed_variables = seed_variables.deep_dup.index_by { |var| var[:key] } + + variables.each_with_object(indexed_seed_variables) do |var, hash| + hash[var[0].to_s] = { key: var[0].to_s, value: var[1], public: true } + end.values + end end def initialize(rule_hashes, default_when:) @@ -32,7 +45,8 @@ module Gitlab Result.new( matched_rule.attributes[:when] || @default_when, matched_rule.attributes[:start_in], - matched_rule.attributes[:allow_failure] + matched_rule.attributes[:allow_failure], + matched_rule.attributes[:variables] ) else Result.new('never') diff --git a/lib/gitlab/ci/config/entry/rules/rule.rb b/lib/gitlab/ci/config/entry/rules/rule.rb index 8ffd49b8a93..840f2d6f31a 100644 --- a/lib/gitlab/ci/config/entry/rules/rule.rb +++ b/lib/gitlab/ci/config/entry/rules/rule.rb @@ -6,14 +6,18 @@ module Gitlab module Entry class Rules::Rule < ::Gitlab::Config::Entry::Node include ::Gitlab::Config::Entry::Validatable + include ::Gitlab::Config::Entry::Configurable include ::Gitlab::Config::Entry::Attributable CLAUSES = %i[if changes exists].freeze - ALLOWED_KEYS = %i[if changes exists when start_in allow_failure].freeze + ALLOWED_KEYS = %i[if changes exists when start_in allow_failure variables].freeze ALLOWABLE_WHEN = %w[on_success on_failure always never manual delayed].freeze attributes :if, :changes, :exists, :when, :start_in, :allow_failure + entry :variables, Entry::Variables, + description: 'Environment variables to define for rule conditions.' + validations do validates :config, presence: true validates :config, type: { with: Hash } diff --git a/lib/gitlab/ci/features.rb b/lib/gitlab/ci/features.rb index c4dca298839..c989b3112e1 100644 --- a/lib/gitlab/ci/features.rb +++ b/lib/gitlab/ci/features.rb @@ -66,6 +66,10 @@ module Gitlab def self.allow_failure_with_exit_codes_enabled? ::Feature.enabled?(:ci_allow_failure_with_exit_codes) end + + def self.rules_variables_enabled?(project) + ::Feature.enabled?(:ci_rules_variables, project, default_enabled: false) + end end end end diff --git a/lib/gitlab/ci/pipeline/seed/build.rb b/lib/gitlab/ci/pipeline/seed/build.rb index 105221dd6af..2271915a72b 100644 --- a/lib/gitlab/ci/pipeline/seed/build.rb +++ b/lib/gitlab/ci/pipeline/seed/build.rb @@ -156,10 +156,12 @@ module Gitlab def rules_attributes strong_memoize(:rules_attributes) do - if @using_rules - rules_result.build_attributes + next {} unless @using_rules + + if ::Gitlab::Ci::Features.rules_variables_enabled?(@pipeline.project) + rules_result.build_attributes(@seed_attributes) else - {} + rules_result.build_attributes end end end diff --git a/locale/gitlab.pot b/locale/gitlab.pot index fa308ca4be3..2a247ab9d8b 100644 --- a/locale/gitlab.pot +++ b/locale/gitlab.pot @@ -4996,6 +4996,30 @@ msgstr "" msgid "Canary weight must be specified and valid range (0..100)." msgstr "" +msgid "CanaryIngress|%{boldStart}Canary:%{boldEnd} %{canary}" +msgstr "" + +msgid "CanaryIngress|%{boldStart}Stable:%{boldEnd} %{stable}" +msgstr "" + +msgid "CanaryIngress|Canary" +msgstr "" + +msgid "CanaryIngress|Change ratio" +msgstr "" + +msgid "CanaryIngress|Change the ratio of canary deployments?" +msgstr "" + +msgid "CanaryIngress|Doing so will set a deployment change in progress. This temporarily blocks any further configuration until the deployment is finished." +msgstr "" + +msgid "CanaryIngress|Stable" +msgstr "" + +msgid "CanaryIngress|You are changing the ratio of the canary rollout for %{environment} compared to the stable deployment to:" +msgstr "" + msgid "Cancel" msgstr "" @@ -23411,6 +23435,9 @@ msgstr "" msgid "RepositoriesAnalytics|Historic Test Coverage Data is available in raw format (.csv) for further analysis." msgstr "" +msgid "RepositoriesAnalytics|Jobs with Coverage" +msgstr "" + msgid "RepositoriesAnalytics|Last Update" msgstr "" @@ -23423,7 +23450,7 @@ msgstr "" msgid "RepositoriesAnalytics|Please select projects to display." msgstr "" -msgid "RepositoriesAnalytics|Projects with Tests" +msgid "RepositoriesAnalytics|Projects with Coverage" msgstr "" msgid "RepositoriesAnalytics|Test Code Coverage" @@ -23432,9 +23459,6 @@ msgstr "" msgid "RepositoriesAnalytics|There was an error fetching the projects." msgstr "" -msgid "RepositoriesAnalytics|Total Number of Coverages" -msgstr "" - msgid "Repository" msgstr "" @@ -25937,6 +25961,9 @@ msgstr "" msgid "Something went wrong, unable to search projects" msgstr "" +msgid "Something went wrong. Please try again later" +msgstr "" + msgid "Something went wrong. Please try again." msgstr "" diff --git a/qa/qa/runtime/env.rb b/qa/qa/runtime/env.rb index d6ac278dbc8..24be4e4f978 100644 --- a/qa/qa/runtime/env.rb +++ b/qa/qa/runtime/env.rb @@ -403,6 +403,10 @@ module QA ENV['GITLAB_QA_USER_AGENT'] end + def geo_environment? + QA::Runtime::Scenario.attributes.include?(:geo_secondary_address) + end + private def remote_grid_credentials diff --git a/qa/qa/specs/features/browser_ui/1_manage/login/2fa_recovery_spec.rb b/qa/qa/specs/features/browser_ui/1_manage/login/2fa_recovery_spec.rb index a6b4a8108a3..e38a9f47bd6 100644 --- a/qa/qa/specs/features/browser_ui/1_manage/login/2fa_recovery_spec.rb +++ b/qa/qa/specs/features/browser_ui/1_manage/login/2fa_recovery_spec.rb @@ -29,7 +29,6 @@ module QA end before do - Runtime::Feature.enable('vue_2fa_recovery_codes', user: developer_user) group.add_member(developer_user, Resource::Members::AccessLevel::DEVELOPER) end @@ -58,7 +57,6 @@ module QA end after do - Runtime::Feature.disable('vue_2fa_recovery_codes', user: developer_user) group.set_require_two_factor_authentication(value: 'false') group.remove_via_api! sandbox_group.remove_via_api! diff --git a/qa/qa/specs/features/browser_ui/1_manage/login/2fa_ssh_recovery_spec.rb b/qa/qa/specs/features/browser_ui/1_manage/login/2fa_ssh_recovery_spec.rb index 7ebbe7887b9..f6d2492c011 100644 --- a/qa/qa/specs/features/browser_ui/1_manage/login/2fa_ssh_recovery_spec.rb +++ b/qa/qa/specs/features/browser_ui/1_manage/login/2fa_ssh_recovery_spec.rb @@ -16,7 +16,6 @@ module QA end before do - Runtime::Feature.enable('vue_2fa_recovery_codes', user: user) enable_2fa_for_user(user) end @@ -47,10 +46,6 @@ module QA expect(page).to have_text('Invalid two-factor code') end - after do - Runtime::Feature.disable('vue_2fa_recovery_codes', user: user) - end - def enable_2fa_for_user(user) Flow::Login.while_signed_in(as: user) do Page::Main::Menu.perform(&:click_settings_link) diff --git a/qa/qa/specs/features/browser_ui/1_manage/login/log_in_with_2fa_spec.rb b/qa/qa/specs/features/browser_ui/1_manage/login/log_in_with_2fa_spec.rb index 1f0215cd929..f81dfe4b5c8 100644 --- a/qa/qa/specs/features/browser_ui/1_manage/login/log_in_with_2fa_spec.rb +++ b/qa/qa/specs/features/browser_ui/1_manage/login/log_in_with_2fa_spec.rb @@ -31,7 +31,6 @@ module QA let(:two_fa_expected_text) { /The group settings for.*require you to enable Two-Factor Authentication for your account.*You need to do this before/ } before do - Runtime::Feature.enable('vue_2fa_recovery_codes', user: developer_user) group.add_member(developer_user, Resource::Members::AccessLevel::DEVELOPER) end @@ -58,7 +57,6 @@ module QA end after do - Runtime::Feature.disable('vue_2fa_recovery_codes', user: developer_user) group.set_require_two_factor_authentication(value: 'false') group.remove_via_api! do |resource| resource.api_client = admin_api_client diff --git a/qa/qa/specs/features/browser_ui/5_package/pypi_repository_spec.rb b/qa/qa/specs/features/browser_ui/5_package/pypi_repository_spec.rb index 6afe086de98..d5eca171d6c 100644 --- a/qa/qa/specs/features/browser_ui/5_package/pypi_repository_spec.rb +++ b/qa/qa/specs/features/browser_ui/5_package/pypi_repository_spec.rb @@ -87,6 +87,7 @@ module QA after do runner.remove_via_api! + project&.remove_via_api! end it 'publishes a pypi package and deletes it', testcase: 'https://gitlab.com/gitlab-org/quality/testcases/-/issues/1087' do @@ -108,6 +109,32 @@ module QA end end end + + context 'Geo', :orchestrated, :geo do + it 'replicates a published pypi package to the Geo secondary site', testcase: 'https://gitlab.com/gitlab-org/quality/testcases/-/issues/1120' do + QA::Runtime::Logger.debug('Visiting the secondary Geo site') + + QA::Flow::Login.while_signed_in(address: :geo_secondary) do + EE::Page::Main::Banner.perform do |banner| + expect(banner).to have_secondary_read_only_banner + end + + Page::Main::Menu.perform(&:go_to_projects) + + Page::Dashboard::Projects.perform do |dashboard| + dashboard.wait_for_project_replication(project.name) + dashboard.go_to_project(project.name) + end + + Page::Project::Menu.perform(&:click_packages_link) + + Page::Project::Packages::Index.perform do |index| + index.wait_for_package_replication(package_name) + expect(index).to have_package(package_name) + end + end + end + end end end end diff --git a/qa/qa/specs/runner.rb b/qa/qa/specs/runner.rb index afeddeaa5d5..9027f17678d 100644 --- a/qa/qa/specs/runner.rb +++ b/qa/qa/specs/runner.rb @@ -40,6 +40,8 @@ module QA tags_for_rspec.push(%w[--tag ~orchestrated]) unless (%w[-t --tag] & options).any? end + tags_for_rspec.push(%w[--tag ~geo]) unless QA::Runtime::Env.geo_environment? + tags_for_rspec.push(%w[--tag ~skip_signup_disabled]) if QA::Runtime::Env.signup_disabled? tags_for_rspec.push(%w[--tag ~skip_live_env]) if QA::Runtime::Env.dot_com? diff --git a/qa/spec/specs/runner_spec.rb b/qa/spec/specs/runner_spec.rb index 8171cfcb3e6..b11054f0bd9 100644 --- a/qa/spec/specs/runner_spec.rb +++ b/qa/spec/specs/runner_spec.rb @@ -3,9 +3,9 @@ require 'active_support/core_ext/hash' RSpec.describe QA::Specs::Runner do - shared_examples 'excludes orchestrated' do - it 'excludes the orchestrated tag and includes default args' do - expect_rspec_runner_arguments(['--tag', '~orchestrated', *described_class::DEFAULT_TEST_PATH_ARGS]) + shared_examples 'excludes orchestrated and geo' do + it 'excludes the orchestrated and geo tags and includes default args' do + expect_rspec_runner_arguments(['--tag', '~orchestrated', '--tag', '~geo', *described_class::DEFAULT_TEST_PATH_ARGS]) subject.perform end @@ -18,13 +18,13 @@ RSpec.describe QA::Specs::Runner do QA::Runtime::Scenario.define(:gitlab_address, "http://gitlab.test") end - it_behaves_like 'excludes orchestrated' + it_behaves_like 'excludes orchestrated and geo' context 'when tty is set' do subject { described_class.new.tap { |runner| runner.tty = true } } it 'sets the `--tty` flag' do - expect_rspec_runner_arguments(['--tty', '--tag', '~orchestrated', *described_class::DEFAULT_TEST_PATH_ARGS]) + expect_rspec_runner_arguments(['--tty', '--tag', '~orchestrated', '--tag', '~geo', *described_class::DEFAULT_TEST_PATH_ARGS]) subject.perform end @@ -34,7 +34,7 @@ RSpec.describe QA::Specs::Runner do subject { described_class.new.tap { |runner| runner.tags = %i[orchestrated github] } } it 'focuses on the given tags' do - expect_rspec_runner_arguments(['--tag', 'orchestrated', '--tag', 'github', *described_class::DEFAULT_TEST_PATH_ARGS]) + expect_rspec_runner_arguments(['--tag', 'orchestrated', '--tag', 'github', '--tag', '~geo', *described_class::DEFAULT_TEST_PATH_ARGS]) subject.perform end @@ -44,7 +44,7 @@ RSpec.describe QA::Specs::Runner do subject { described_class.new.tap { |runner| runner.options = %w[--tag smoke] } } it 'focuses on the given tag without excluded the orchestrated tag' do - expect_rspec_runner_arguments(['--tag', 'smoke', *described_class::DEFAULT_TEST_PATH_ARGS]) + expect_rspec_runner_arguments(['--tag', '~geo', '--tag', 'smoke', *described_class::DEFAULT_TEST_PATH_ARGS]) subject.perform end @@ -53,8 +53,8 @@ RSpec.describe QA::Specs::Runner do context 'when "qa/specs/features/foo" is set as options' do subject { described_class.new.tap { |runner| runner.options = %w[qa/specs/features/foo] } } - it 'passes the given tests path and excludes the orchestrated tag' do - expect_rspec_runner_arguments(['--tag', '~orchestrated', 'qa/specs/features/foo']) + it 'passes the given tests path and excludes the orchestrated and geo tags' do + expect_rspec_runner_arguments(['--tag', '~orchestrated', '--tag', '~geo', 'qa/specs/features/foo']) subject.perform end @@ -64,7 +64,7 @@ RSpec.describe QA::Specs::Runner do subject { described_class.new.tap { |runner| runner.options = %w[--tag smoke qa/specs/features/foo] } } it 'focuses on the given tag and includes the path without excluding the orchestrated tag' do - expect_rspec_runner_arguments(['--tag', 'smoke', 'qa/specs/features/foo']) + expect_rspec_runner_arguments(['--tag', '~geo', '--tag', 'smoke', 'qa/specs/features/foo']) subject.perform end @@ -76,7 +76,7 @@ RSpec.describe QA::Specs::Runner do end it 'includes default args and excludes the skip_signup_disabled tag' do - expect_rspec_runner_arguments(['--tag', '~orchestrated', '--tag', '~skip_signup_disabled', *described_class::DEFAULT_TEST_PATH_ARGS]) + expect_rspec_runner_arguments(['--tag', '~orchestrated', '--tag', '~geo', '--tag', '~skip_signup_disabled', *described_class::DEFAULT_TEST_PATH_ARGS]) subject.perform end @@ -88,8 +88,24 @@ RSpec.describe QA::Specs::Runner do end it 'includes default args and excludes the skip_live_env tag' do - expect_rspec_runner_arguments(['--tag', '~orchestrated', '--tag', '~skip_live_env', *described_class::DEFAULT_TEST_PATH_ARGS]) + expect_rspec_runner_arguments(['--tag', '~orchestrated', '--tag', '~geo', '--tag', '~skip_live_env', *described_class::DEFAULT_TEST_PATH_ARGS]) + subject.perform + end + end + + context 'when running against a Geo environment' do + before do + QA::Runtime::Scenario.define(:geo_secondary_address, "https://geo.staging.gitlab.com") + end + + after do + QA::Runtime::Scenario.attributes.delete(:geo_secondary_address) + end + + subject { described_class.new.tap { |runner| runner.tags = %i[geo] } } + it 'includes the geo tag' do + expect_rspec_runner_arguments(['--tag', 'geo', *described_class::DEFAULT_TEST_PATH_ARGS]) subject.perform end end @@ -105,7 +121,7 @@ RSpec.describe QA::Specs::Runner do end it 'includes default args and excludes all unsupported tags' do - expect_rspec_runner_arguments(['--tag', '~orchestrated', *excluded_feature_tags_except(feature), *described_class::DEFAULT_TEST_PATH_ARGS]) + expect_rspec_runner_arguments(['--tag', '~orchestrated', '--tag', '~geo', *excluded_feature_tags_except(feature), *described_class::DEFAULT_TEST_PATH_ARGS]) subject.perform end @@ -130,11 +146,11 @@ RSpec.describe QA::Specs::Runner do end end - it_behaves_like 'excludes orchestrated' + it_behaves_like 'excludes orchestrated and geo' end context 'when features are not specified' do - it_behaves_like 'excludes orchestrated' + it_behaves_like 'excludes orchestrated and geo' end end diff --git a/spec/features/projects/environments/environments_spec.rb b/spec/features/projects/environments/environments_spec.rb index b207d415ce0..27167f95104 100644 --- a/spec/features/projects/environments/environments_spec.rb +++ b/spec/features/projects/environments/environments_spec.rb @@ -454,10 +454,10 @@ RSpec.describe 'Environments page', :js do expect(page).to have_content 'review-1' expect(page).to have_content 'review-2' within('.ci-table') do - within('.gl-responsive-table-row:nth-child(3)') do + within('[data-qa-selector="environment_item"]', text: 'review-1') do expect(find('.js-auto-stop').text).not_to be_empty end - within('.gl-responsive-table-row:nth-child(4)') do + within('[data-qa-selector="environment_item"]', text: 'review-2') do expect(find('.js-auto-stop').text).not_to be_empty end end diff --git a/spec/fixtures/whats_new/20201225_01_01.yml b/spec/fixtures/whats_new/20201225_01_01.yml index 48248757b9a..7bf58900cc7 100644 --- a/spec/fixtures/whats_new/20201225_01_01.yml +++ b/spec/fixtures/whats_new/20201225_01_01.yml @@ -1,5 +1,7 @@ --- - title: It's gonna be a bright + body: | + ## It's gonna be a bright self-managed: true gitlab-com: false packages: ["Premium", "Ultimate"] diff --git a/spec/fixtures/whats_new/20201225_01_02.yml b/spec/fixtures/whats_new/20201225_01_02.yml index f0fbc036698..90b5192897e 100644 --- a/spec/fixtures/whats_new/20201225_01_02.yml +++ b/spec/fixtures/whats_new/20201225_01_02.yml @@ -1,5 +1,7 @@ --- - title: bright + body: | + ## bright self-managed: true gitlab-com: false packages: ["Premium", "Ultimate"] diff --git a/spec/fixtures/whats_new/20201225_01_05.yml b/spec/fixtures/whats_new/20201225_01_05.yml index 152609296c9..27c8f989b08 100644 --- a/spec/fixtures/whats_new/20201225_01_05.yml +++ b/spec/fixtures/whats_new/20201225_01_05.yml @@ -1,10 +1,14 @@ --- - title: bright and sunshinin' day + body: | + ## bright and sunshinin' day self-managed: true gitlab-com: false packages: ["Premium", "Ultimate"] release: '01.05' - title: I think I can make it now the pain is gone + body: | + ## I think I can make it now the pain is gone self-managed: false gitlab-com: true packages: ["Premium", "Ultimate"] diff --git a/spec/graphql/resolvers/user_notes_count_resolver_spec.rb b/spec/graphql/resolvers/user_notes_count_resolver_spec.rb index 5b036f9c556..3cb0810c698 100644 --- a/spec/graphql/resolvers/user_notes_count_resolver_spec.rb +++ b/spec/graphql/resolvers/user_notes_count_resolver_spec.rb @@ -41,7 +41,7 @@ RSpec.describe Resolvers::UserNotesCountResolver do end end - context 'when a user does not have permission to view discussions' do + context 'when a user does not have permission to view notes' do subject { batch_sync { resolve_user_notes_count(private_issue) } } it 'returns no notes' do @@ -77,7 +77,7 @@ RSpec.describe Resolvers::UserNotesCountResolver do end end - context 'when a user does not have permission to view discussions' do + context 'when a user does not have permission to view notes' do subject { batch_sync { resolve_user_notes_count(private_merge_request) } } it 'returns no notes' do diff --git a/spec/lib/gitlab/ci/build/rules/rule/clause_spec.rb b/spec/lib/gitlab/ci/build/rules/rule/clause_spec.rb new file mode 100644 index 00000000000..faede7a361f --- /dev/null +++ b/spec/lib/gitlab/ci/build/rules/rule/clause_spec.rb @@ -0,0 +1,37 @@ +# frozen_string_literal: true + +require 'spec_helper' + +RSpec.describe Gitlab::Ci::Build::Rules::Rule::Clause do + describe '.fabricate' do + using RSpec::Parameterized::TableSyntax + + let(:value) { 'some value' } + + subject { described_class.fabricate(type, value) } + + context 'when type is valid' do + where(:type, :result) do + 'changes' | Gitlab::Ci::Build::Rules::Rule::Clause::Changes + 'exists' | Gitlab::Ci::Build::Rules::Rule::Clause::Exists + 'if' | Gitlab::Ci::Build::Rules::Rule::Clause::If + end + + with_them do + it { is_expected.to be_instance_of(result) } + end + end + + context 'when type is invalid' do + let(:type) { 'when' } + + it { is_expected.to be_nil } + + context "when type is 'variables'" do + let(:type) { 'variables' } + + it { is_expected.to be_nil } + end + end + end +end diff --git a/spec/lib/gitlab/ci/build/rules_spec.rb b/spec/lib/gitlab/ci/build/rules_spec.rb index ba99650396d..a1af5b75f87 100644 --- a/spec/lib/gitlab/ci/build/rules_spec.rb +++ b/spec/lib/gitlab/ci/build/rules_spec.rb @@ -104,7 +104,7 @@ RSpec.describe Gitlab::Ci::Build::Rules do context 'with one rule without any clauses' do let(:rule_list) { [{ when: 'manual', allow_failure: true }] } - it { is_expected.to eq(described_class::Result.new('manual', nil, true)) } + it { is_expected.to eq(described_class::Result.new('manual', nil, true, nil)) } end context 'with one matching rule' do @@ -171,7 +171,7 @@ RSpec.describe Gitlab::Ci::Build::Rules do context 'with matching rule' do let(:rule_list) { [{ if: '$VAR == null', allow_failure: true }] } - it { is_expected.to eq(described_class::Result.new('on_success', nil, true)) } + it { is_expected.to eq(described_class::Result.new('on_success', nil, true, nil)) } end context 'with non-matching rule' do @@ -180,25 +180,61 @@ RSpec.describe Gitlab::Ci::Build::Rules do it { is_expected.to eq(described_class::Result.new('never')) } end end + + context 'with variables' do + context 'with matching rule' do + let(:rule_list) { [{ if: '$VAR == null', variables: { MY_VAR: 'my var' } }] } + + it { is_expected.to eq(described_class::Result.new('on_success', nil, nil, { MY_VAR: 'my var' })) } + end + end end describe 'Gitlab::Ci::Build::Rules::Result' do let(:when_value) { 'on_success' } let(:start_in) { nil } let(:allow_failure) { nil } + let(:variables) { nil } subject(:result) do - Gitlab::Ci::Build::Rules::Result.new(when_value, start_in, allow_failure) + Gitlab::Ci::Build::Rules::Result.new(when_value, start_in, allow_failure, variables) end describe '#build_attributes' do + let(:seed_attributes) { {} } + subject(:build_attributes) do - result.build_attributes + result.build_attributes(seed_attributes) end it 'compacts nil values' do is_expected.to eq(options: {}, when: 'on_success') end + + context 'when there are variables in rules' do + let(:variables) { { VAR1: 'new var 1', VAR3: 'var 3' } } + + context 'when there are seed variables' do + let(:seed_attributes) do + { yaml_variables: [{ key: 'VAR1', value: 'var 1', public: true }, + { key: 'VAR2', value: 'var 2', public: true }] } + end + + it 'returns yaml_variables with override' do + is_expected.to include( + yaml_variables: [{ key: 'VAR1', value: 'new var 1', public: true }, + { key: 'VAR2', value: 'var 2', public: true }, + { key: 'VAR3', value: 'var 3', public: true }] + ) + end + end + + context 'when there is not seed variables' do + it 'does not return yaml_variables' do + is_expected.not_to have_key(:yaml_variables) + end + end + end end describe '#pass?' do @@ -206,7 +242,7 @@ RSpec.describe Gitlab::Ci::Build::Rules do let!(:when_value) { 'never' } it 'returns false' do - expect(subject.pass?).to eq(false) + expect(result.pass?).to eq(false) end end @@ -214,7 +250,7 @@ RSpec.describe Gitlab::Ci::Build::Rules do let!(:when_value) { 'on_success' } it 'returns true' do - expect(subject.pass?).to eq(true) + expect(result.pass?).to eq(true) end end end diff --git a/spec/lib/gitlab/ci/config/entry/rules/rule_spec.rb b/spec/lib/gitlab/ci/config/entry/rules/rule_spec.rb index 4a43e6c9a86..d1bd22e5573 100644 --- a/spec/lib/gitlab/ci/config/entry/rules/rule_spec.rb +++ b/spec/lib/gitlab/ci/config/entry/rules/rule_spec.rb @@ -339,6 +339,22 @@ RSpec.describe Gitlab::Ci::Config::Entry::Rules::Rule do end end end + + context 'with an invalid variables' do + let(:config) do + { if: '$THIS == "that"', variables: 'hello' } + end + + before do + subject.compose! + end + + it { is_expected.not_to be_valid } + + it 'returns an error about invalid variables:' do + expect(subject.errors).to include(/variables config should be a hash of key value pairs/) + end + end end context 'allow_failure: validation' do diff --git a/spec/lib/gitlab/ci/pipeline/seed/build_spec.rb b/spec/lib/gitlab/ci/pipeline/seed/build_spec.rb index 3cbc498c3a4..bc10e94c81d 100644 --- a/spec/lib/gitlab/ci/pipeline/seed/build_spec.rb +++ b/spec/lib/gitlab/ci/pipeline/seed/build_spec.rb @@ -71,6 +71,33 @@ RSpec.describe Gitlab::Ci::Pipeline::Seed::Build do end end + context 'with job:rules:[variables:]' do + let(:attributes) do + { name: 'rspec', + ref: 'master', + yaml_variables: [{ key: 'VAR1', value: 'var 1', public: true }, + { key: 'VAR2', value: 'var 2', public: true }], + rules: [{ if: '$VAR == null', variables: { VAR1: 'new var 1', VAR3: 'var 3' } }] } + end + + it do + is_expected.to include(yaml_variables: [{ key: 'VAR1', value: 'new var 1', public: true }, + { key: 'VAR2', value: 'var 2', public: true }, + { key: 'VAR3', value: 'var 3', public: true }]) + end + + context 'when FF ci_rules_variables is disabled' do + before do + stub_feature_flags(ci_rules_variables: false) + end + + it do + is_expected.to include(yaml_variables: [{ key: 'VAR1', value: 'var 1', public: true }, + { key: 'VAR2', value: 'var 2', public: true }]) + end + end + end + context 'with cache:key' do let(:attributes) do { diff --git a/spec/models/release_highlight_spec.rb b/spec/models/release_highlight_spec.rb index c7d411c96ec..ac252e6d6cf 100644 --- a/spec/models/release_highlight_spec.rb +++ b/spec/models/release_highlight_spec.rb @@ -86,6 +86,17 @@ RSpec.describe ReleaseHighlight do expect(subject[:next_page]).to eq(2) end + it 'parses the body as markdown and returns html' do + expect(subject[:items].first['body']).to match("<h2 id=\"bright-and-sunshinin-day\">bright and sunshinin’ day</h2>") + end + + it 'logs an error if theres an error parsing markdown for an item, and skips it' do + allow(Kramdown::Document).to receive(:new).and_raise + + expect(Gitlab::ErrorTracking).to receive(:track_exception) + expect(subject[:items]).to be_empty + end + context 'when Gitlab.com' do let(:dot_com) { true } @@ -95,14 +106,11 @@ RSpec.describe ReleaseHighlight do end end - context 'when recent release items do NOT exist' do - before do + context 'YAML parsing throws an exception' do + it 'fails gracefully and logs an error' do allow(YAML).to receive(:safe_load).and_raise(Psych::Exception) expect(Gitlab::ErrorTracking).to receive(:track_exception) - end - - it 'fails gracefully and logs an error' do expect(subject).to be_nil end end diff --git a/spec/services/ci/create_pipeline_service/rules_spec.rb b/spec/services/ci/create_pipeline_service/rules_spec.rb index a18c8f23ee7..ac6c4c188e4 100644 --- a/spec/services/ci/create_pipeline_service/rules_spec.rb +++ b/spec/services/ci/create_pipeline_service/rules_spec.rb @@ -160,6 +160,81 @@ RSpec.describe Ci::CreatePipelineService do end end end + + context 'if:' do + context 'variables:' do + let(:config) do + <<-EOY + job: + script: "echo job1" + variables: + VAR1: my var 1 + VAR2: my var 2 + rules: + - if: $CI_COMMIT_REF_NAME =~ /master/ + variables: + VAR1: overridden var 1 + - if: $CI_COMMIT_REF_NAME =~ /feature/ + variables: + VAR2: overridden var 2 + VAR3: new var 3 + - when: on_success + EOY + end + + let(:job) { pipeline.builds.find_by(name: 'job') } + + context 'when matching to the first rule' do + let(:ref) { 'refs/heads/master' } + + it 'overrides VAR1' do + variables = job.scoped_variables_hash + + expect(variables['VAR1']).to eq('overridden var 1') + expect(variables['VAR2']).to eq('my var 2') + expect(variables['VAR3']).to be_nil + end + + context 'when FF ci_rules_variables is disabled' do + before do + stub_feature_flags(ci_rules_variables: false) + end + + it 'does not affect variables' do + variables = job.scoped_variables_hash + + expect(variables['VAR1']).to eq('my var 1') + expect(variables['VAR2']).to eq('my var 2') + expect(variables['VAR3']).to be_nil + end + end + end + + context 'when matching to the second rule' do + let(:ref) { 'refs/heads/feature' } + + it 'overrides VAR2 and adds VAR3' do + variables = job.scoped_variables_hash + + expect(variables['VAR1']).to eq('my var 1') + expect(variables['VAR2']).to eq('overridden var 2') + expect(variables['VAR3']).to eq('new var 3') + end + end + + context 'when no match' do + let(:ref) { 'refs/heads/wip' } + + it 'does not affect vars' do + variables = job.scoped_variables_hash + + expect(variables['VAR1']).to eq('my var 1') + expect(variables['VAR2']).to eq('my var 2') + expect(variables['VAR3']).to be_nil + end + end + end + end end context 'when workflow:rules are used' do |
