[peholmst]

Fixes the failed CI run on main after #14 (run), and makes CI keep main in sync with the tutorial from now on.

What failed

• Verify add-tests. docs: use the context API and locators for all browserless tests docs#6508 rewrote the Add Tests step. It now adds BrowserlessContextConfiguration in src/test/java/com/example. The generator put a class in the test sources only if it imported JUnit, so this class landed in src/main/java. It imports the test-scoped browserless library, so it didn't compile there.
• Check that main matches the last step. main came from October's docs and skeleton. Since then, the tests were rewritten, Vaadin went from 25.3.2 to 25.3.5, Spring Boot from 4.1.1 to 4.1.2, and the skeleton moved the app shell from Application to a new AppShell class.
• Publish step branches was skipped as a result, so the step/* branches don't exist yet.

Commits

1. Put classes that use test libraries in the test sources. The generator now treats a class as test code if it imports JUnit, browserless, Spring test, Mockito, AssertJ, Hamcrest, or TestBench.

2. Update main to the current tutorial. Generated from vaadin/docs v25.3 at 83124bb. The README also mentions the new test configuration.

3. Open a pull request when main drifts from the tutorial. Each Vaadin maintenance release changes the skeleton, so main will drift almost weekly. A new update-main job runs on main (push, schedule, and manual runs) after every step has passed verification. It calls update-main.sh, which:

   • replaces everything except README.md and .github with the last step, and removes files that the last step no longer has,
   • force-pushes the result to the update-main branch and opens a pull request, or updates the one that is open,
   • does nothing if the branch already has the same changes on the current main,
   • closes the pull request and deletes its branch when main matches again.

   The check of main still fails on pull requests and on main while it drifts. Its error message now points to the update pull request.

Token and CI trigger trade-off

The job uses GITHUB_TOKEN, with contents, pull-requests, and actions write permissions. The repository already lets GitHub Actions create pull requests. However, GitHub doesn't start workflows for events that GITHUB_TOKEN causes, so the update pull request would get no checks on its own. The script therefore starts CI on the update-main branch with gh workflow run. workflow_dispatch is one of the events that GITHUB_TOKEN can trigger. The checks of that run are on the pull request's head commit, so they show up on the pull request. The alternative, a PAT or a GitHub App token, would make the pull request trigger CI normally, but it needs a secret that someone has to own and rotate. I chose the dispatch.

How it was verified

• All nine steps regenerated from docs v25.3 pass ./mvnw verify. Add Tests runs 6 tests, with 0 failures. main on this branch passes too, and matches the last step.
• update-main.sh in a scratch clone, with a local bare repository as origin:
  • On the current main, it produces exactly the files of commit 2, apart from the README, and leaves README.md and .github alone.
  • It removes a tracked file that the last step doesn't have.
  • It reports "already has these changes" when the remote branch has the same changes on the same main. When main has moved, it makes a new commit.
  • It reports a match, and does nothing else, on this branch.
• The --push path ran against the bare repository, with a stub gh that logs its arguments. It ran pr create when no pull request was open and pr edit when one was, followed by workflow run ci.yml --ref update-main, and pr close --delete-branch once main matched. The real gh calls haven't run yet. The first schedule or push after main drifts again will exercise them.

After merging

The CI run on main should pass, and publish the step/* branches for the first time. update-main should report that main matches.

🤖 Generated with Claude Code