anchor.diff:    <tr>
       <td><code>key</code></td>
       <td>
  -	A unique string to identify the block step.
  +    	A unique string to identify the block step.
         <em>Example:</em> <code>"test-suite"</code>
       </td>
     </tr>  
  
positive.code: Parallel groups will be displayed ungrouped if the build's jobs are truncated because Buildkite doesn't currently store or calculate any information about the number of jobs in a non-parallel group.
  
  If a parallel step exists within a group, parallel jobs are treated as simple jobs within a step group - so you can't have parallel groups within step groups. So, for example, a `group` that contains two `steps` each with `parallel: 4` will display eight jobs in it, with no visual indication that those eight jobs are two parallel steps. 
  <!-- vale on -->
  
  ## Limitations in job groups
   
  There exist several limitations regarding the job groups' behavior:
   
  * Only the first 100 jobs within a build header will be displayed, so you might not see all of your groups at all times. However, the jobs are fine and will still show up on the build page. 
  * It's impossible to have a parallel job with only some of the jobs within a group, as they're all created on the same YAML step entry.
  * Sub-groups and nested groups are not supported.
  * If a parallel job group is within a named group, the groups are handled as though the parallel group isn't there.
   
  ## Using wait steps in job groups
   
  You can have [wait steps]() in a group. Such steps operate independently of other groups. For example, both groups will operate independently here, meaning "d" won't wait on "a" to finish:
  ```yml
  steps:
    - group: "111"
      depends_on: "tests"
      steps:
        - command: "a.sh"
        - wait
        - command: "b.sh"
  
    - group: "222"
      depends_on: "tests"
      id: "toast"
      steps:
        - command: "c.sh"
        - wait
        - command: "d.sh"
  
    - command: "yay.sh"
      depends_on: "toast"
  ```
  {: codeblock-file="pipeline.yml"}
  
  ## Group merging  
  
  Different droups that have the same name are merged together in the UI. 
  
  For example, if you have a YAML file:
  
  ```yml
  - group: "Setup"
    steps:
      - command: "buildkite agent pipeline upload"
  ```
  {: codeblock-file="pipeline-01.yml"}
  
  And this YAML file uploads a pipeline that has a group with the same name:
  
  ```yml
  - group: "Setup"
    steps:
      - command: "docker build"
  ```yml
  {: codeblock-file="pipeline-02.yml"}
  
  As a result, the groups will be merged into one in the UI and the `"docker build"` step will be added to the existing group.
  
  [image placeholder]
  
negative.code: # Group Step
   
  A *group* step groups jobs and steps like block step, trigger step, command step, etc. (but not other group steps) into logical groups, and allows displaying them within groups on the build page in Buildkite UI.  
  
  For example, your build pipelines in Buildkite are able to support an unlimited number of jobs. However, a large number of jobs on the build page can look messy. If pipelines contain 4-5 steps that can be logically grouped together, you can put them in a group using the `group` step.  
  
  The group step also helps manage dependencies between a collection of steps in a DAG (for example, step X depends on everything in a group Y).
  
  ```
  <section class="Docs__note">
    <h3>Note</h3>
    <p>In some cases, using group step might break the DAG visualisation feature.</p>
  </section>
  ```    
  
  {:toc}
   
  A group step can be defined in your pipeline settings or your [pipeline.yml](/docs/pipelines/defining-steps) file.  
  
  This is what a typical group step use looks like:
  
  