chore(ci): target Dependabot at develop and add PR checks - #92
Merged
Conversation
Two gaps found while reviewing the open PRs. 1. There was no .github/dependabot.yml at all, so Dependabot fell back to the repository default branch (master) and opened every update against it. master is release-only here, so all four open bumps (#77, #79, #80, #90) had to be retargeted by hand before they could be merged. Add a config with target-branch: develop for npm, gomod and github-actions. The npm entry also groups routine dev-dependency minor/patch updates, because separate PRs all edit web-portal/package-lock.json and therefore conflict with each other - they have to be merged one at a time with a rebase in between. Major bumps of vite and @sveltejs/vite-plugin-svelte are ignored deliberately: vite 7 -> 8 swaps the bundler from rollup+esbuild to rolldown, which changes the JavaScript we ship inside the firmware image and deserves an explicit decision rather than arriving as "chore(deps-dev)". Ignore rules do not affect security updates, which still come through. 2. No workflow triggered on pull_request: build-swu and develop-test-build are workflow_dispatch, auto-release is push-on-tag, gh-pages-deploy is push-to-master. So a dependency bump that breaks the frontend build was only discovered at release time, when the Docker image build failed. Add a PR workflow running npm ci + npm run build for web-portal (only when web-portal actually changed) and the pytest suite. Deliberately does not build the SWU - that needs the ARM toolchain and is far too slow for a PR gate.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Two gaps found while reviewing the open PRs. Both are causes, not symptoms.
1. Dependabot had no config, so it targeted
masterThere is no
.github/dependabot.ymlon any branch (verified withgit log --all). Dependabot therefore fell back to the repository default branch, which ismaster. That is why all four open bumps (#77, #79, #80, #90) arrived targeting the release-only branch and had to be retargeted by hand before they could be merged.Adds a config with
target-branch: developfor npm (/web-portal), gomod (the web portal's Go backend) and github-actions.Two deliberate choices in the npm entry:
web-portal/package-lock.json, so separate PRs conflict with one another and must be merged one at a time with a rebase in between - exactly what happened this round. Grouping keeps routine churn to a single lockfile change.viteand@sveltejs/vite-plugin-svelteare ignored. chore(deps-dev): bump vite and @sveltejs/vite-plugin-svelte in /web-portal #80 is the reason: presented aschore(deps-dev), it is actually vite 7→8 plus plugin 6→7, which swaps the bundler from rollup+esbuild to rolldown (54 packages removed, 30 added) and quietly carries a@tailwindcss/vitebump. That changes the JavaScript we ship inside the firmware image and deserves a deliberate decision. Note ignore rules do not suppress security updates, which still come through.2. Nothing ran on pull requests
Confirmed across all four existing workflows:
build-swuanddevelop-test-buildareworkflow_dispatch,auto-releaseis push-on-tag,gh-pages-deployis push-to-master.statusCheckRollupwas empty on every open PR - theirBLOCKEDstate isREVIEW_REQUIRED, not a failing check.So
npm ci && npm run buildhad never run on any of the four dependency PRs. A bump that breaks the frontend would only surface at release time, when the Docker image build fails.Adds a
pull_requestworkflow with two cheap jobs:npm ci+npm run build, skipped unlessweb-portal/actually changed. Node 22 to match the Dockerfile'sbuild-web-uistage.pytest tests/ -qsuite (28 tests).Deliberately not building the SWU here: that needs the ARM toolchain and is far too slow for a PR gate.
Verification
Both files parse as valid YAML. I also ran the frontend build locally against the just-merged develop (dompurify 3.4.12, kit 2.69.3, svelte 5.56.5) and it succeeds - so this workflow should be green on arrival rather than landing red.