We've added a lot to our demo project, bun--create-playwright.
We've explored setting up a Playwright framework using bun, a new package manager bundled into Claude Code. We've added typechecking, and formatting and linting. We've set up a CI/ CD pipeline for our tests using GitLab, one with three stages:
- Quality: We check that the formatting, linting and typechecking is correct for any changes we attempt to push to the code base.
- Test: We run the smoke and then the regression tests to make sure that everything still works.
- Report: We bundle an archive of the Playwright generated HTML report, with screenshots and videos if things fail.
For this post, we will add a new stage to this GitLab pipeline:
- Deploy: Where we will deploy the HTML report to GitLab Pages, so we can view it online.
What is GitLab Pages?
GitLab Pages is a built-in feature of GitLab that allows you to publish static websites directly from a repository in GitLab. Similar to GitHub Pages, it is commonly used to host project documentation, personal blogs, portfolios, or corporate landing pages for free.
From the GitLab Docs / Pages: "To use GitLab Pages, you must create a project in GitLab to upload your website’s files to. These projects can be either public, internal, or private.
"By default, GitLab deploys your website from a specific folder called public in your repository. You can also set a custom folder to be deployed with Pages. When you create a new project in GitLab, a repository becomes available automatically.
"To deploy your site, GitLab uses its built-in tool called GitLab CI/CD to build your site and publish it to the GitLab Pages server. The sequence of scripts that GitLab CI/CD runs to accomplish this task is created from a file named .gitlab-ci.yml, which you can create and modify. A user-defined job with pages: true property in the configuration file makes GitLab aware that you’re deploying a GitLab Pages website.
"You can either use the GitLab default domain for GitLab Pages websites, *.gitlab.io, or your own domain (example.com). In that case, you must be an administrator in your domain’s registrar (or control panel) to set it up with Pages".
How To Confirm That GitLab Pages is Set Up
- Go to bun-create-playwright
- Go to Settings > General.
- Expand Visibility, project features, permissions.
- Confirm the Pages toggle is on.
... It seems that GitLab Pages is turned on by default for new projects. We'd only see it off if someone disabled it. (See GitLab Pages access control docs).
"The pages:deploy job is an internal, automatically generated 'magic' job in GitLab CI/CD that runs immediately after your user-defined pages job finishes successfully to upload and publish your static website.
Create a New Pages Job In the Report Stage in .Gitlab-ci.yml
We will add the following code to our GitLab bun-create-playwright project, building on the Report stage we created earlier, adding a new "pages" job.
pages:
stage: report
image: alpine:3.24
needs:
- job: playwright
artifacts: true
optional: true
- job: playwright:manual
artifacts: true
optional: true
rules:
- if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
script:
- echo "Deploying Playwright HTML report to GitLab Pages"
pages:
publish: playwright-report
Here, in the pages job:
- We are adding this pages job to the "report" stage.
- We are using the lightweight Docker image, Alpine 3.24, a small Linux distribution.
- It needs the earlier "playwright" job that ran the Playwright tests to finish. It pulls in the artifacts saved by that job -- the screenshots, HTML report, etc. And it is optional, so if the previous job fails, due to tests erroring out, we will still run this job.
- Also, it does not matter if it came from the regular playwright job created when someone pushed changes and a pipeline was created, or if someone created a brand new pipeline. This job will run.
Rules: We are only going to run this job of the commit is on the default branch on main, so pages won't get republished from every feature branch.
We print out the message that we are deploying...
Then we use in the Pages stage the GitLab keyword Publish to take everything in the playwright-report folder, containing the HTML Report as an index.html file, and publish that as a website.
Once we create this new stage, let's push the changes and see what happens...
Verify Everything is Correct ... and PUSH!
Let's make sure everything is in the correct format:
- Check against the TypeScript compiler: bun run typecheck
- Fix any formatting issues with Prettier: bun run format
- Fix any linting issues with ES Lint: bun run lint:fix
Pushing the changes onto our main branch:
- git add .
- git commit -m "chore: Push Report to GitLab Pages"
- git push
Did Everything Pass?
Okay, let's check everything in the new pipeline generated when we just pushed the new stage in the .gitlab-ci.yml file onto the main branch...
- Quality stage: All Green!
- Test Stage: All Green!
- Report Stage, with the new pages stage we just created... all green!
- And a new Deploy stage is generated with a pages:deploy job.
"Purpose: It separates the build/compile phase (which you control in your custom pages job) from the actual hosting deployment handled safely by GitLab". [ GitLab Docs / Deployment Process ].
Is Everything Deployed?
Is Everything Published on GitLab Pages?
Yes! We now have Playwright's HTML Report deployed to GitLab pages!
Note: Each time there is a change, this GitLab doc will be overwritten and only the latest results will be shown.
Next, we will be looking at another possible solution to reports... called ReportPortal.
Until then, Happy Testing!
Bun Create Playwright:
- Part One: Introducing bun, a new package manager and JavaScript runtime environment
- Part Two: What happens when you scaffold a Playwright framework and run installed tests using bun?
- Part Three: Add Type Checking and TSConfig to Bun-Create-Playwright
- Part Four: Checking code with lint, formatting it with prettier
- Part Five: Running Tests with Playwright Test Explorer and Generating Tests with Codegen
- Part Six: How Playwright Frameworks get configured with playwright.config.ts
- Part Seven: Implementing Page Objects in Playwright
- Part Eight: How to Configure Playwright Test to run smoke tests, headed tests, and debug versions through scripts in package.json
- Part Nine: Setting up a CI/ CD pipeline with GitLab: Quality, Test and Report
- Part Ten: How Developers Can Test Their Feature Branch Against Various Playwright Configurations Before Creating a Merge Request in GitLab CI/CD
- Part Eleven: Examining the artifacts job of a Playwright GitLab CI / CD pipeline
- Part Twelve: Publishing Playwright HTML reports on GitLab Pages
- GitLab: https://gitlab.com/tjmaher/bun-create-playwright
No comments:
Post a Comment