Automatic merge of gitlab-org/gitlab master

app/assets/javascripts/pipeline_editor/components/file_nav/branch_switcher.vue

@@ -212,6 +212,7 @@ export default {
     :text="currentBranch"
     icon="branch"
     data-qa-selector="branch_selector_button"
+    data-testid="branch-selector"
   >
     <gl-search-box-by-type :debounce="$options.inputDebounce" @input="setSearchTerm" />
     <gl-dropdown-section-header>

doc/administration/gitaly/index.md

@@ -152,8 +152,8 @@ The availability objectives for Gitaly clusters are:
   second. Failover requires ten consecutive failed health checks on each
   Praefect node.
 
-  [Faster outage detection](https://gitlab.com/gitlab-org/gitaly/-/issues/2608)
-  is planned to improve this to less than 1 second.
+  Faster outage detection, to improve this speed to less than 1 second,
+  is tracked [in this issue](https://gitlab.com/gitlab-org/gitaly/-/issues/2608).
 
 ### Virtual storage
 
@@ -176,8 +176,8 @@ The number of repository replicas can be configured using a
 
 It can
 be uneconomical to have the same replication factor for all repositories.
-[Variable replication factor](https://gitlab.com/groups/gitlab-org/-/epics/3372) is planned to
-provide greater flexibility for extremely large GitLab instances.
+To provide greater flexibility for extremely large GitLab instances,
+variable replication factor is tracked in [this issue](https://gitlab.com/groups/gitlab-org/-/epics/3372).
 
 As with normal Gitaly storages, virtual storages can be sharded.
 

doc/administration/raketasks/uploads/migrate.md

@@ -133,9 +133,9 @@ migrate your data out of object storage and back into your local storage.
 
 WARNING:
 **Extended downtime is required** so no new files are created in object storage during
-the migration. A configuration setting is planned to allow migrating
-from object storage to local files with only a brief moment of downtime for configuration changes.
-To follow progress, see the [relevant issue](https://gitlab.com/gitlab-org/gitlab/-/issues/30979).
+the migration. A configuration setting to allow migrating
+from object storage to local files with only a brief moment of downtime for configuration changes
+is tracked [in this issue](https://gitlab.com/gitlab-org/gitlab/-/issues/30979).
 
 ### All-in-one Rake task
 

doc/ci/interactive_web_terminal/index.md

@@ -33,8 +33,8 @@ Two things need to be configured for the interactive web terminal to work:
 
 NOTE:
 Interactive web terminals are not yet supported by
-[`gitlab-runner` Helm chart](https://docs.gitlab.com/charts/charts/gitlab/gitlab-runner/index.html),
-but support [is planned](https://gitlab.com/gitlab-org/charts/gitlab-runner/-/issues/79).
+[`gitlab-runner` Helm chart](https://docs.gitlab.com/charts/charts/gitlab/gitlab-runner/index.html).
+Support is tracked [in this issue](https://gitlab.com/gitlab-org/charts/gitlab-runner/-/issues/79).
 
 ## Debugging a running job
 

doc/ci/secrets/index.md

@@ -91,8 +91,7 @@ To configure your Vault server:
    - `VAULT_AUTH_PATH` - (Optional) The path where the authentication method is mounted, default is `jwt`.
 
    NOTE:
-   Support for [providing these values in the user interface](https://gitlab.com/gitlab-org/gitlab/-/issues/218677)
-   is planned but not yet implemented.
+   Support for providing these values in the user interface [is tracked in this issue](https://gitlab.com/gitlab-org/gitlab/-/issues/218677).
 
 ## Use Vault secrets in a CI job **(PREMIUM)**
 

doc/ci/yaml/index.md

@@ -1575,7 +1575,7 @@ production:
   name, they overwrite each other and only the last one downloaded is saved.
 - `needs:` is similar to `dependencies:` in that it must use jobs from prior stages,
   meaning it's impossible to create circular dependencies. Depending on jobs in the
-  current stage is not possible either, but support [is planned](https://gitlab.com/gitlab-org/gitlab/-/issues/30632).
+  current stage is not possible either, but [an issue exists](https://gitlab.com/gitlab-org/gitlab/-/issues/30632).
 - Stages must be explicitly defined for all jobs
   that have the keyword `needs:` or are referred to by one.
 

doc/development/documentation/styleguide/index.md

@@ -1585,6 +1585,18 @@ For example:
 - In GitLab 12.2 and earlier, ...
 - In GitLab 11.6 and later, ...
 
+### Promising features in future versions
+
+Do not promise to deliver features in a future release. For example, avoid phrases like,
+"Support for this feature is planned."
+
+We cannot guarantee future feature work, and promises
+like these can raise legal issues. Instead, say that an issue exists, for example,
+"Support for this feature is tracked [in this issue]." Or, "Improvements to
+this functionality are tracked [in this issue]."
+
+You _can_ say that we plan to remove a feature.
+
 ### Removing versions after each major release
 
 Whenever a major GitLab release occurs, we remove all version references

doc/development/feature_flags/controls.md

@@ -96,18 +96,18 @@ Guidelines:
 
 #### Process
 
-Before toggling any feature flag, check that there are no ongoing
-significant incidents on GitLab.com. You can do this by checking the
-`#production` and `#incident-management` Slack channels, or looking for
-[open incident issues](https://gitlab.com/gitlab-com/gl-infra/production/-/issues/?scope=all&state=opened&label_name[]=incident)
-(although check the dates and times).
-
-We do not want to introduce changes during an incident, as it can make
-diagnosis and resolution of the incident much harder to achieve, and
-also will largely invalidate your rollout process as you will be unable
-to assess whether the rollout was without problems or not.
-
-If there is any doubt, ask in `#production`.
+When enabling a feature flag rollout, the system will automatically block the
+chatops command from succeeding if there are active `"severity::1"` or `~"severity::2"`
+incidents or in-progress change issues, for example:
+
+```shell
+/chatops run feature set gitaly_lfs_pointers_pipeline true
+
+- Production checks fail!
+- active incidents
+
+  2021-06-29 Canary deployment failing QA tests
+```
 
 The following `/chatops` commands should be performed in the Slack
 `#production` channel.

doc/development/testing_guide/frontend_testing.md

@@ -51,7 +51,7 @@ which have to be stubbed.
 
 ### Differences to Karma
 
-- Jest runs in a Node.js environment, not in a browser. Support for running Jest tests in a browser [is planned](https://gitlab.com/gitlab-org/gitlab/-/issues/26982).
+- Jest runs in a Node.js environment, not in a browser. [An issue exists](https://gitlab.com/gitlab-org/gitlab/-/issues/26982) for running Jest tests in a browser.
 - Because Jest runs in a Node.js environment, it uses [jsdom](https://github.com/jsdom/jsdom) by default. See also its [limitations](#limitations-of-jsdom) below.
 - Jest does not have access to Webpack loaders or aliases.
   The aliases used by Jest are defined in its [own configuration](https://gitlab.com/gitlab-org/gitlab/-/blob/master/jest.config.js).

doc/development/uploads.md

@@ -120,7 +120,8 @@ We have three kinds of file encoding in our uploads:
 
 1. <i class="fa fa-check-circle"></i> **multipart**: `multipart/form-data` is the most common, a file is encoded as a part of a multipart encoded request.
 1. <i class="fa fa-check-circle"></i> **body**: some APIs uploads files as the whole request body.
-1. <i class="fa fa-times-circle"></i> **JSON**: some JSON API uploads files as base64 encoded strings. This requires a change to GitLab Workhorse, which [is planned](https://gitlab.com/gitlab-org/gitlab-workhorse/-/issues/226).
+1. <i class="fa fa-times-circle"></i> **JSON**: some JSON API uploads files as base64 encoded strings. This requires a change to GitLab Workhorse,
+   which is tracked [in this issue](https://gitlab.com/gitlab-org/gitlab/-/issues/325068).
 
 ## Uploading technologies
 

doc/integration/jira/connect-app.md

@@ -53,7 +53,7 @@ After a namespace is added:
   are synced to Jira.
 - From GitLab 13.8, past merge request data is synced to Jira.
 
-Support for syncing past branch and commit data [is planned](https://gitlab.com/gitlab-org/gitlab/-/issues/263240).
+Support for syncing past branch and commit data is tracked [in this issue](https://gitlab.com/gitlab-org/gitlab/-/issues/263240).
 
 ## Install the GitLab.com for Jira Cloud app for self-managed instances **(FREE SELF)**
 

doc/user/admin_area/moderate_users.md

@@ -221,7 +221,6 @@ Users can be banned using the Admin Area. To do this:
 NOTE:
 This feature is a work in progress. Currently, banning a user
 only blocks them and does not hide their comments or issues.
-This functionality is planned to be implemented in follow up issues.
 
 ### Unban a user
 

doc/user/application_security/container_scanning/index.md

@@ -160,8 +160,8 @@ You can [configure](#customizing-the-container-scanning-settings) analyzers by u
 | `CS_REGISTRY_INSECURE`         | `"false"`     | Allow access to insecure registries (HTTP only). Should only be set to `true` when testing the image locally. | Trivy. The registry must listen on port `80/tcp`. |
 | `CS_SEVERITY_THRESHOLD`        | `UNKNOWN`     | Severity level threshold. The scanner outputs vulnerabilities with severity level higher than or equal to this threshold. Supported levels are Unknown, Low, Medium, High, and Critical. | Trivy |
 | `DOCKER_IMAGE`                 | `$CI_APPLICATION_REPOSITORY:$CI_APPLICATION_TAG` | The Docker image to be scanned. If set, this variable overrides the `$CI_APPLICATION_REPOSITORY` and `$CI_APPLICATION_TAG` variables. | All |
-| `DOCKER_PASSWORD`              | `$CI_REGISTRY_PASSWORD` | Password for accessing a Docker registry requiring authentication. | All |
-| `DOCKER_USER`                  | `$CI_REGISTRY_USER` | Username for accessing a Docker registry requiring authentication. | All |
+| `DOCKER_PASSWORD`              | `$CI_REGISTRY_PASSWORD` | Password for accessing a Docker registry requiring authentication. The default is only set if `$DOCKER_IMAGE` resides at [`$CI_REGISTRY`](../../../ci/variables/predefined_variables.md). | All |
+| `DOCKER_USER`                  | `$CI_REGISTRY_USER` | Username for accessing a Docker registry requiring authentication. The default is only set if `$DOCKER_IMAGE` resides at [`$CI_REGISTRY`](../../../ci/variables/predefined_variables.md). | All |
 | `DOCKERFILE_PATH`              | `Dockerfile`  | The path to the `Dockerfile` to use for generating remediations. By default, the scanner looks for a file named `Dockerfile` in the root directory of the project. You should configure this variable only if your `Dockerfile` is in a non-standard location, such as a subdirectory. See [Solutions for vulnerabilities](#solutions-for-vulnerabilities-auto-remediation) for more details. | All |
 | `SECURE_LOG_LEVEL`             | `info`        | Set the minimum logging level. Messages of this logging level or higher are output. From highest to lowest severity, the logging levels are: `fatal`, `error`, `warn`, `info`, `debug`. [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/10880) in GitLab 13.1. | All |
 

doc/user/packages/container_registry/index.md

@@ -488,8 +488,8 @@ To delete the underlying layers and images that aren't associated with any tags,
 Cleanup policies can be run on all projects, with these exceptions:
 
 - For GitLab.com, the project must have been created after 2020-02-22.
-  Support for projects created earlier
-  [is planned](https://gitlab.com/gitlab-org/gitlab/-/issues/196124).
+  Support for projects created earlier is tracked
+  [in this issue](https://gitlab.com/gitlab-org/gitlab/-/issues/196124).
 - For self-managed GitLab instances, the project must have been created
   in GitLab 12.8 or later. However, an administrator can enable the cleanup policy
   for all projects (even those created before 12.8) in

doc/user/project/issues/design_management.md

@@ -48,7 +48,7 @@ If the requirements are not met, the **Designs** tab displays a message to the u
 Files uploaded must have a file extension of either `png`, `jpg`, `jpeg`,
 `gif`, `bmp`, `tiff`, `ico`, `webp`, or `svg`.
 
-Support for [PDF](https://gitlab.com/gitlab-org/gitlab/-/issues/32811) is planned for a future release.
+Support for PDF is tracked [in this issue](https://gitlab.com/gitlab-org/gitlab/-/issues/32811).
 
 ## Limitations
 

doc/user/project/merge_requests/cherry_pick_changes.md

@@ -37,7 +37,8 @@ request thread. It crosslinks the new commit and the existing merge request.
 Each deployment's [list of associated merge requests](../../../api/deployments.md#list-of-merge-requests-associated-with-a-deployment) includes cherry-picked merge commits.
 
 NOTE:
-We only track cherry-pick executed from GitLab (both UI and API). Support for [tracking cherry-picked commits through the command line](https://gitlab.com/gitlab-org/gitlab/-/issues/202215) is planned for a future release.
+We only track cherry-pick executed from GitLab (both UI and API). Support for tracking cherry-picked commits through the command line
+is tracked [in this issue](https://gitlab.com/gitlab-org/gitlab/-/issues/202215).
 
 ## Cherry-picking a commit
 

doc/user/project/wiki/index.md

@@ -225,7 +225,7 @@ A `_sidebar` example, formatted with Markdown:
 - [Sidebar](_sidebar)
 ```
 
-Support for displaying a generated table of contents with a custom side navigation is planned.
+Support for displaying a generated table of contents with a custom side navigation is being considered.
 
 ## Enable or disable a project wiki
 

doc/user/snippets.md

@@ -215,8 +215,7 @@ which can encourage user collaboration.
 - Git tags are not supported in snippet repositories.
 - Snippets' repositories are limited to 10 files. Attempting to push more
   than 10 files results in an error.
-- Revisions are not visible to the user on the GitLab UI, but this feature is planned
-  in future iterations. See the [revisions tab issue](https://gitlab.com/gitlab-org/gitlab/-/issues/39271)
+- Revisions are not visible to the user on the GitLab UI, but [an issue exists](https://gitlab.com/gitlab-org/gitlab/-/issues/39271)
   for updates.
 - The [maximum size for a snippet](../administration/snippets/index.md#snippets-content-size-limit)
   is 50 MB, by default.

spec/features/projects/ci/editor_spec.rb

@@ -5,17 +5,55 @@ require 'spec_helper'
 RSpec.describe 'Pipeline Editor', :js do
   include Spec::Support::Helpers::Features::SourceEditorSpecHelpers
 
-  let(:project) { create(:project, :repository) }
+  let(:project) { create(:project_empty_repo, :public) }
   let(:user) { create(:user) }
 
+  let(:default_branch) { 'main' }
+  let(:other_branch) { 'test' }
+
   before do
     sign_in(user)
     project.add_developer(user)
 
+    project.repository.create_file(user, project.ci_config_path_or_default, 'Default Content', message: 'Create CI file for main', branch_name: default_branch)
+    project.repository.create_file(user, project.ci_config_path_or_default, 'Other Content', message: 'Create CI file for test', branch_name: other_branch)
+
     visit project_ci_pipeline_editor_path(project)
+    wait_for_requests
   end
 
   it 'user sees the Pipeline Editor page' do
     expect(page).to have_content('Pipeline Editor')
   end
+
+  context 'branch switcher' do
+    before do
+      stub_feature_flags(pipeline_editor_branch_switcher: true)
+    end
+
+    def switch_to_branch(branch)
+      find('[data-testid="branch-selector"]').click
+
+      page.within '[data-testid="branch-selector"]' do
+        click_button branch
+        wait_for_requests
+      end
+    end
+
+    it 'displays current branch' do
+      page.within('[data-testid="branch-selector"]') do
+        expect(page).to have_content(default_branch)
+        expect(page).not_to have_content(other_branch)
+      end
+    end
+
+    it 'displays updated current branch after switching branches' do
+      switch_to_branch(other_branch)
+
+      page.within('[data-testid="branch-selector"]') do
+        expect(page).to have_content(other_branch)
+        expect(page).not_to have_content(default_branch)
+      end
+    end
+  end
 end