Jobs being grouped on anchor's name?

Hi there

I’m doing something like this

default:
  image: mcr.microsoft.com/playwright
  before_script:
    - node --version
    - npm --version
    - npm ci
    - npx playwright --version
    - npx playwright install
    - export env=$(echo $CI_JOB_NAME | cut -d' ' -f1)
    - export spec="tests/$(echo $CI_JOB_NAME | cut -d' ' -f2).spec.ts"

.test: &test
  script:
    - npx playwright test $spec
  rules:
    - when: manual
  artifacts:
    when: always
    paths:
      - playwright-report/
      - test-results/
      - results.xml
    reports:
      junit: results.xml

# dev env

dev AdminTool: *test
dev Login: *test
dev UserOnboarding: *test
dev WebAppProfile: *test
dev WebAppSales: *test
dev Website: *test

# qa env

qa AdminTool: *test
qa Login: *test
# ...

I expect the UI to group the jobs by env : “dev”, “qa”, etc. But I got only one “test” column, seems it’s grouping based on the anchor’s name. Tried chaging anchor & .test name around, also different syntax

qa Login:
  <<: *test

Not better. How can I get a clean result here ?

Pipelines support stages that allow grouping certain jobs together, and only when one stage completes successfully, the next stage is started. CI/CD pipelines | GitLab

I’m not sure if that’s what you are looking for with grouping, maybe you can share more details about where you learned about pipeline job groups in GitLab?

The test stage is the default stage name if jobs do not specifically define the stages they are in. GitLab comes with default stages: `.gitlab-ci.yml` keyword reference | GitLab . You can re-use the default, or define your own stages.

Adding stages to your example can look like this. 1) stages definition on top 2) stage keyword in jobs.

stages:
  - dev
  - qa
 
.test: &test
  script:
    - npx playwright test $spec
  rules:
    - when: manual
  artifacts:
    when: always
    paths:
      - playwright-report/
      - test-results/
      - results.xml
    reports:
      junit: results.xml

dev AdminTool: 
  <<: *test
  stage: dev

dev Login:
  <<: *test
  stage: dev

qa AdminTool: 
  <<: *test
  stage: qa

qa Login:
  <<: *test
  stage: qa

You could also create an additional template layer which inherits .test and adds the stage. I’m not sure how this works with YAML anchors though, the extends keyword is more readable in this regard. I’ll try with the example above, tested in the CI/CD > Pipeline Editor.

stages:
  - dev
  - qa
 
.test: 
  script:
    - npx playwright test $spec
  rules:
    - when: manual
  artifacts:
    when: always
    paths:
      - playwright-report/
      - test-results/
      - results.xml
    reports:
      junit: results.xml

# Templates extending the .test job and defining different stages
.test-dev:
  extends: .test
  stage: dev 

.test-qa:
  extends: .test
  stage: qa

# Job definitions extending the different job templates and stages 
dev AdminTool: 
  extends: .test-dev 

dev Login:
  extends: .test-dev 

qa AdminTool: 
  extends: .test-qa

qa Login:
  extends: .test-qa

Config in the Pipeline Editor | GitLab

Turns out I was a bit confused after reading this bit of doc, I only retained there was this automagic grouping on steps names and not really the specific.

Anyway, I could achieve what I wanted with a combination of stages & needs: []

stages:
  - dev
  - dev1
  - ...
  - prod

default:
  image: mcr.microsoft.com/playwright
  before_script:
    - node --version
    - npm --version
    - npm ci
    - npx playwright --version
    - npx playwright install
    # Getting job environment & spec file configuration from job name
    - export server=$(echo $CI_JOB_NAME | cut -d' ' -f1)
    - export spec="tests/$(echo $CI_JOB_NAME | cut -d' ' -f2).spec.ts"

.test: &test
  needs: []
  script:
    - npx playwright test $spec
  rules:
    - when: manual
  artifacts:
    when: always
    paths:
      - playwright-report/
      - test-results/
      - results.xml
    reports:
      junit: results.xml

# dev env

dev AdminTool:
  <<: *test
  stage: dev
dev Login:
  <<: *test
  stage: dev
...

# dev1 env

dev1 AdminTool:
  <<: *test
  stage: dev1
dev1 Login:
  <<: *test
  stage: dev1
...

And the result I was looking for

1 Like

Great to see you found a solution, thanks for sharing with us :heart: