Automatic merge of gitlab-org/gitlab-ce master

app/assets/javascripts/ide/components/branches/search_list.vue

@@ -58,8 +58,7 @@ export default {
 
 <template>
   <div>
-    <div class="dropdown-input mt-3 pb-3 mb-0 border-bottom">
-      <div class="position-relative">
+    <label class="dropdown-input pt-3 pb-3 mb-0 border-bottom block position-relative" @click.stop>
       <input
         ref="searchInput"
         v-model="search"
@@ -68,16 +67,15 @@ export default {
         class="form-control dropdown-input-field"
         @input="searchBranches"
       />
-        <icon :size="18" name="search" class="input-icon" />
-      </div>
-    </div>
+      <icon :size="18" name="search" class="ml-3 input-icon" />
+    </label>
     <div class="dropdown-content ide-merge-requests-dropdown-content d-flex">
       <gl-loading-icon
         v-if="isLoading"
         :size="2"
         class="mt-3 mb-3 align-self-center ml-auto mr-auto"
       />
-      <ul v-else class="mb-3 w-100">
+      <ul v-else class="mb-0 w-100">
         <template v-if="hasBranches">
           <li v-for="item in branches" :key="item.name">
             <item :item="item" :project-id="currentProjectId" :is-active="isActiveBranch(item)" />

app/assets/javascripts/ide/components/merge_requests/list.vue

@@ -76,8 +76,7 @@ export default {
 
 <template>
   <div>
-    <div class="dropdown-input mt-3 pb-3 mb-0 border-bottom">
-      <div class="position-relative">
+    <label class="dropdown-input pt-3 pb-3 mb-0 border-bottom block" @click.stop>
       <tokened-input
         v-model="search"
         :tokens="searchTokens"
@@ -86,9 +85,8 @@ export default {
         @input="searchMergeRequests"
         @removeToken="setSearchType(null)"
       />
-        <icon :size="18" name="search" class="input-icon" />
-      </div>
-    </div>
+      <icon :size="18" name="search" class="ml-3 input-icon" />
+    </label>
     <div class="dropdown-content ide-merge-requests-dropdown-content d-flex">
       <gl-loading-icon
         v-if="isLoading"
@@ -96,7 +94,7 @@ export default {
         class="mt-3 mb-3 align-self-center ml-auto mr-auto"
       />
       <template v-else>
-        <ul class="mb-3 w-100">
+        <ul class="mb-0 w-100">
           <template v-if="showSearchTypes">
             <li v-for="searchType in $options.searchTypes" :key="searchType.type">
               <button
@@ -107,7 +105,7 @@ export default {
                 <span class="d-flex append-right-default ide-search-list-current-icon">
                   <icon :size="18" name="search" />
                 </span>
-                <span> {{ searchType.label }} </span>
+                <span>{{ searchType.label }}</span>
               </button>
             </li>
           </template>

app/assets/stylesheets/page_bundles/ide.scss

@@ -1216,11 +1216,10 @@ $ide-commit-header-height: 48px;
 }
 
 .ide-search-list-empty {
-  height: 230px;
+  height: 69px;
 }
 
 .ide-merge-requests-dropdown-content {
-  min-height: 230px;
   max-height: 470px;
 }
 

changelogs/unreleased/61332-web-ide-mr-branch-dropdown-closes-unexpectedly.yml

+---
+title: Fix an issue where clicking outside the MR/branch search box in WebIDE closed the dropdown.
+merge_request: 31523
+author:
+type: fixed

doc/ci/jenkins/index.md

@@ -30,6 +30,34 @@ There are some high level differences between the products worth mentioning:
 - GitLab comes with a [container registry](../../user/project/container_registry.md), and we recommend using
   container images to set up your build environment.
 
+## Groovy vs. YAML
+
+Jenkins Pipelines are based on [Groovy](https://groovy-lang.org/), so the pipeline specification is written as code. 
+GitLab works a bit differently, we use the more highly structured [YAML](https://yaml.org/) format, which
+places scripting elements inside of `script:` blocks separate from the pipeline specification itself.
+
+This is a strength of GitLab, in that it helps keep the learning curve much simpler to get up and running
+and avoids some of the problem of unconstrained complexity which can make your Jenkinsfiles hard to understand
+and manage.
+
+That said, we do of course still value DRY (don't repeat yourself) principles and want to ensure that
+behaviors of your jobs can be codified once and applied as needed. You can use the `extends:` syntax to
+[templatize your jobs](../yaml/README.md#extends), and `include:` can be used to [bring in entire sets of behaviors](../yaml/README.md#include)
+to pipelines in different projects.
+
+```yaml
+.in-docker:
+  tags:
+    - docker
+  image: alpine
+
+rspec:
+  extends:
+    - .in-docker
+  script:
+    - rake rspec
+```      
+
 ## Artifact publishing
 
 Artifacts may work a bit differently than you've used them with Jenkins. In GitLab, any job can define

doc/ci/variables/predefined_variables.md

@@ -30,7 +30,7 @@ future GitLab releases.**
 | `CI_BUILDS_DIR`                         | all    | 11.10  | Top-level directory where builds are executed. |
 | `CI_CONCURRENT_ID`                      | all    | 11.10  | Unique ID of build execution within a single executor. |
 | `CI_CONCURRENT_PROJECT_ID`              | all    | 11.10  | Unique ID of build execution within a single executor and project. |
-| `CI_COMMIT_BEFORE_SHA`                  | 11.2   | all    | The previous latest commit present on a branch before a push request. Only populated when there is a merge request associated with the pipeline. |
+| `CI_COMMIT_BEFORE_SHA`                  | 11.2   | all    | The previous latest commit present on a branch before a merge request. Only populated when there is a merge request associated with the pipeline. |
 | `CI_COMMIT_DESCRIPTION`                 | 10.8   | all    | The description of the commit: the message without first line, if the title is shorter than 100 characters; full message in other case. |
 | `CI_COMMIT_MESSAGE`                     | 10.8   | all    | The full commit message. |
 | `CI_COMMIT_REF_NAME`                    | 9.0    | all    | The branch or tag name for which project is built |

doc/user/project/repository/web_editor.md

@@ -105,7 +105,7 @@ Once you click it, a new branch will be created that diverges from the default
 branch of your project, by default `master`. The branch name will be based on
 the title of the issue and as a prefix, it will have its internal ID. Thus, the example
 screenshot above will yield a branch named
-`2-et-cum-et-sed-expedita-repellat-consequatur-ut-assumenda-numquam-rerum`.
+`23177-add-support-for-rich-references-to-referables`.
 
 Since GitLab 9.0, when you click the `New branch` in an empty repository project, GitLab automatically creates the master branch, commits a blank `README.md` file to it and creates and redirects you to a new branch based on the issue title.
 If your [project is already configured with a deployment service][project-services-doc] (e.g. Kubernetes), GitLab takes one step further and prompts you to set up [auto deploy][auto-deploy-doc] by helping you create a `.gitlab-ci.yml` file.