I have a repo with testcases that are run using CI. The testreport (a static HTML Site) gets deployed to pages. Since the testcases differ on each branch I wanted to have reports for multiple branches availiable.
I thought the runner automatically gets the currently deployed pages folder, so I used <pages_url>/<branch_name> by placing the site in subfolders inside the pages folder.
Now I realize, that the currently deployed version of pages does not get provided as an artifact automatically.
The Docs seem to mention that pages are also artifacts and could be acessed by url, but I have yet to figure out how that works.
The job in the .gitlab-ci.yml looks like this:
pages:
tags:
- docker //to get a docker runner in my gitlab instance
when: always
image: ubuntu:latest
stage: upload_report
script:
- mkdir public
- rm -r public/$CI_COMMIT_BRANCH || true
- mv ./reports/html-report public/$CI_COMMIT_BRANCH
- "echo Report is acessible at: $REPORT_URL"
artifacts:
paths:
- public
expire_in: 2 days
Thanks for any help on this. I’m still quite new to CI so if you see anything improvable, please let me know.
How you tackle this will depend a little bit on how you want to use the reports.
To have one single site with all the reports for all the branches is hard. There isn’t a built-in way to do this in GitLab, so you would need to run your tests on one branch, then commit and push the results to a common branch which held your pages site. You would also have to think about how to clean those HTML files up once you merge feature branches into your default branch.
An easier option, is to use review apps which are ephemeral and will exist within merge requests. This way, you will keep separate “sites” for the different branches, but you won’t need to worry about cleaning up GitLab pages once each MR is merged. OTOH you won’t be able to compare results between branches so easily, and of course you may be using review apps for something else!
To give you an idea of how the second option would work, you might want something like this:
pages:
image: ubuntu:latest
stage: upload_report
rules:
# Only run on feature branches
- if: '$CI_COMMIT_BRANCH == "main"'
when: never
- when: on_success
script:
- mkdir -p public
# Changed this slightly, so public/index.html might exist
- mv ./reports/html-report/* public/
environment:
environment:
name: review/$CI_COMMIT_REF_NAME
url: "https://$CI_PROJECT_NAMESPACE.gitlab.io/-/$CI_PROJECT_NAME/-/jobs/$CI_JOB_ID/artifacts/public/index.html"
artifacts:
paths:
- public
expire_in: 2 days
tags:
- docker
This makes use of an environment and some predefined variables. If you are using a subgroup within your group, the environment.url will look something like https://GROUP.gitlab.io/-/SUBGROUP/$CI_PROJECT_NAME/....
If you do this, your MR should have a new button called View latest app which should take you to the report, or you can browse the files from the pipeline page.
The other other option, is not to generate HTML from your tests, but generate a JUnit-like XML file and expose that in the GitLab UI, but of course that won’t be as friendly as your HTML report.