Upgrade dependencies, runtimes and PDS version #117
Labels
No labels
No milestone
No project
No assignees
2 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
Grandiras/Ponente#117
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
🤖 On it — follow along in the action run; the reply will link the full session transcript.
📜 Live transcript — updating every ~5 minutes while the task runs.
Everything is pushed and the working tree is clean. Writing the reply.
Pushed
claude/issue-117— one commit, no behaviour change.What moved
release.ymlThe vstest runner 4.0.0 is not a migration — its nuspec says it runs v1, v2 and v3 tests, so xunit stays on v2. SortableJS 1.15.7 is two upstream bug fixes and no API change; the vendored file was byte-identical to the upstream 1.15.6 dist and still is for 1.15.7.
What deliberately did not move, and why
sdk:10.0/aspnet:10.0already float onto the current patch.dotnet list package --outdatedis now empty for the app project.pg_upgradeagainstdb-dataon both deployed stacks, not a tag edit. Filed as its own issue.actions/checkoutstays at v4. The runner's job container isnode:22-bookworm(I read it off the daemon), and v5+ declareusing: node24— a bump would fail at "Setup job". Written intoci.yml's runner notes.:latest, and this is the answer to the "PDS version" part of the issue: there is no version in this repository to bump. Upstream publisheslatest,beta, a moving0.4, and one immutable semver tag —0.4.0, which is the February 2024 build.latestis0.4.5027, built 2026-08-11, and pinning to the tag that looks like a version would take the PDS two years backwards. It is pulled bycompose pullinsidedeploy.sh; the unattended timer only moves the app image. So upgrading the PDS is a deploy, not a commit — now written down indocs/deployment.md.Verified
The runner's job container can reach the dind daemon on the default gateway (the trick
release.ymlalready uses), so this was checked against real things rather than by inspection:dotnet build+ 295/295 unit tests green.<script>is stripped,javascript:hrefs are emptied,ToPlainTextkeeps link destinations.The 22 failures are the environment, not the bumps.
boards.spec.js:99fails 3 times out of 3 on an unmodified tree and 2 of 3 with the bumps, and driving the page by hand pins the cause: the delete button on/admin/boardsdoes nothing when clicked immediately after the navigation and works when the identical click is made six seconds later — the prerender/circuit-attach race the suite wins on a normal machine.docs/testing.mdclaimed CI "has no container engine to start the stack with"; that is now corrected to what is true (there is one, reachable) plus the real reason not to wire e2e into CI — it comes back red for reasons no pull request caused.Docs updated in the same commit:
deployment.md(third-party image tags),frontend.md(how to re-vendor SortableJS),testing.md(the above). NoChangelog.Unreleasedentry — no member would notice any of this.The stack and volumes I created on the shared dind host are torn down.
⏱ 34m 34s · 155 turns · tokens: 156.6k in / 61.3k out (+17249.5k cache-read)
📜 Full session transcript
→ Opened PR: #118
→ Filed follow-up issue #119: Plan the Postgres 17 → 18 upgrade (it is a pg_upgrade, not a tag edit)
→ Filed follow-up issue #120: The build's one warning: CS8604 on the calendar day cell's conditional @onclick