Bump pytest from 8.4.2 to 9.0.3 in /docker/check-runners/python#6
Open
dependabot[bot] wants to merge 2 commits into
Open
Bump pytest from 8.4.2 to 9.0.3 in /docker/check-runners/python#6dependabot[bot] wants to merge 2 commits into
dependabot[bot] wants to merge 2 commits into
Conversation
Source: platform_server main @ 0ed784c Generated by: scripts/publish_to_serverclaw.py Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Bumps [pytest](https://github.com/pytest-dev/pytest) from 8.4.2 to 9.0.3. - [Release notes](https://github.com/pytest-dev/pytest/releases) - [Changelog](https://github.com/pytest-dev/pytest/blob/main/CHANGELOG.rst) - [Commits](pytest-dev/pytest@8.4.2...9.0.3) --- updated-dependencies: - dependency-name: pytest dependency-version: 9.0.3 dependency-type: direct:production ... Signed-off-by: dependabot[bot] <support@github.com>
dependabot
Bot
added
dependencies
baditaflorin
force-pushed
the
main
branch
2 times, most recently
from
7c1f5d7 to
e12f901
Compare
baditaflorin
added a commit
that referenced
this pull request
Apr 23, 2026
* [bootstrap] fresh-host end-to-end through Stage 4 — 7 gaps closed Live-validated against a fresh Hetzner AX41-NVMe running the 0fork overlay. Each fix is the root cause of a distinct fresh-host bootstrap failure observed on the 65.109.84.223 box over attempts #7 through #12. Proxmox API validation (bootstrap #6 → #7) - Added `proxmox_api_validate_certs` default to gate the controller's TLS verification against the PVE API. Defaults to true; overlays that set `proxmox_security_manage_acme=false` (e.g. during Hetzner DNS brownout, when ACME cannot issue a real cert) flip this to false so token probes succeed against the self-signed pveproxy cert. Host control-loop idempotency (bootstrap #7 → #8) - `systemctl reset-failed` returns rc=1 with "Unit not loaded" on fresh hosts where the control-loop service has never run. That is the desired state; tolerate it with `failed_when`. Bootstrap verifier auth handling (bootstrap #8 → #9) - `/api2/json/version` correctly returns 401 for anonymous requests once the automation token is provisioned. Accept both 200 and 401; read the version via `pveversion` instead of API JSON. step_ca arg-spec fallback (bootstrap #9 → #10) - Role argument-spec validation runs as `tags: always`, i.e. before ADR 0373's `derive_service_defaults` sets the conventional vars. Added a literal default for `step_ca_compose_file` matching the derived value so tag-filtered site.yml runs don't fail arg-spec. Stage 3/4 playbook scoping (bootstrap #10 → #11) - `configure-network`, `harden-access`, and `provision-guests` now run against `proxmox-install.yml` instead of `site.yml`. The `network`, `repository`, `access`, and `guests` tags only live on proxmox-install plays. Going via site.yml imports every service group, triggers arg-spec validation (always) on every `*_runtime` role, and cascades into "missing required arguments" errors for ADR-0373-derived vars that aren't set until task-run time. Keeping Stage 3/4 targeted at proxmox-install keeps arg-spec scoped to host roles with static vars. New proxmox_base_template role (bootstrap #11 → #12) - `proxmox_guests` requires the Debian 13 cloud-init template (VMID 9000) to already exist. On fresh hosts this step was documented only as ad-hoc shell in the Hetzner runbook. Codified into an idempotent Ansible role: downloads debian-13-genericcloud-amd64.qcow2, creates the template VM, imports the disk, attaches a cloud-init snippet, converts to template, and polls `pvesh /cluster/resources` until the cluster cache reflects template=1 (avoids a race where proxmox_guests runs the assertion before pve-cluster's in-memory cache refreshes). - Wired into `playbooks/proxmox-install.yml` before proxmox_guests with both `guests` and `base-template` tags. Stage 4 now completes cleanly on a fresh host: all 17 guest VMs cloned, configured, and started in one make-bootstrap invocation. * [bootstrap] declare ws-0424 ownership of fresh-host bootstrap fixes Adds an owned-surfaces group covering the 11 files changed in the preceding bootstrap commit, so the workstream-surface gate passes.
baditaflorin
added a commit
that referenced
this pull request
Apr 23, 2026
…(#33) * [diary] append 2026-04-22 evening findings — Stages 2-4 now green Documents the 7 fresh-host gaps closed across bootstrap attempts #6-#12, the whack-a-mole realization on site.yml arg-spec cascades, the new proxmox_base_template role, and the pvesh cache-lag retry. Diary-only change — no code surface. * fork-bootstrap: verify-bootstrap-guests tolerates unknown env values Fork deployments set env=clone, which the host-pattern mapping in verify-bootstrap-guests.yml did not know about. Jinja2 dict subscript raised `object of type 'dict' has no attribute 'clone'` and the playbook never started. Collapse any env not present in the mapping to `production` so unknown envs resolve to the canonical `lv3_guests` group instead of crashing. Behavior for `production` and `staging` is unchanged. Part of ADR 0424 fork-clone validation; surfaced while proceeding into Stage 5 convergence on fork-pve-01. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.7 <noreply@anthropic.com>
baditaflorin
added a commit
that referenced
this pull request
Apr 23, 2026
…r cloud-init update (#36) * fork-bootstrap: register converge-site in workflow catalog Stage 5 of `make bootstrap` (introduced 2026-04-09) calls `make preflight WORKFLOW=converge-site`, but the workflow was never added to config/workflow-catalog.json. Every fresh-host bootstrap attempt failed with "Unknown workflow: converge-site" the moment Stages 2-4 finished green. Register converge-site as a sibling of live-apply-site: - requires bootstrap_ssh_private_key + controller-local-base manifest - mutation execution_class - 5400s budget for full-platform converge across 32 hosts Why a new workflow rather than reusing live-apply-site: the live-apply target also runs check-canonical-truth, vulnerability_budget, and service_redundancy gates, all of which assume a steady-state platform. Stage 5 must succeed on a freshly bootstrapped host before any of those gates can be satisfied; live-apply remains the right path for day-2 reconverges. Part of ADR 0424 fork-clone validation. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com> * fork-bootstrap: multi-inventory + bypass scope runner for converge-site Three gaps that blocked Stage 5 of `make bootstrap` on a fresh host when PLATFORM_IDENTITY_OVERLAY is set (ADR 0437 / ADR 0424): 1. ansible_scope_runner rejected multi-inventory CLI `--inventory A -i B` silently dumped the `-i B` tail into the `ansible_args` REMAINDER and the planner only saw the first inventory. argparse's REMAINDER eats anything beginning with `-` once the first positional slot is filled. Fix: pre-normalise `-i PATH` -> `--inventory PATH` before argparse runs (stopping at the first `--` sentinel so downstream passthroughs stay untouched), switch `--inventory` to an appendable list, and thread `inventory_paths` end-to-end through plan_playbook_execution, run_planned_playbook, and discover_target_hosts so every ansible-playbook/inventory subprocess gets every `-i`. 2. converge-site cannot be planned by the scope catalog site.yml composes nested `import_playbook` + Jinja2 ternaries that the scope runner's hosts-expression grammar can't resolve. For the bootstrap path we need to run the full collection site playbook unmediated; otherwise the planner errors out before a single task runs. This is the same trade-off live-apply-site already accepts. Fix: converge-site now calls `ansible-playbook` directly with both inventories, `proxmox_guest_ssh_connection_mode=proxmox_host_jump`, the overlay extra-vars wiring, and the bootstrap key. Preflight and validate workflow wiring unchanged. 3. PLATFORM_IDENTITY_OVERLAY was resolved relative to the worktree Worktrees intentionally lack `.local/` (ADR 0376), so a value like `.local/identity.yml.0fork` crashed with "Could not find or access" even though the overlay existed at the main repo's `.local/`. Fix: if PLATFORM_IDENTITY_OVERLAY is a relative path starting with `.local/`, rewrite it through LOCAL_OVERLAY_ROOT (which already resolves to the main repo's `.local/` in worktree context). Stage 5 run #4 with this stack applied is now actively converging through the proxmox_network role on fork-pve-01 -- the first time the one-command bootstrap has crossed into Stage 5 on a fresh host. Workstream manifest: add the two scoped-runner files to ws_0424_overlay_aware_bootstrap. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com> * fork-bootstrap: emit overlay host_vars next to overlay inventory Stage 4 (guest provisioning) on a fresh host consulted the committed inventory/host_vars/proxmox-host.yml (which has production 10.10.10.X guest IPs) instead of the fork's .local/host_vars/proxmox-host.yml (which intended 10.20.10.X for subnet isolation). Cloud-init baked 10.10.10.X into the 17 guests, while the generated overlay inventory declared ansible_host=10.20.10.X for SSH — so Stage 5 tried to reach hosts that did not exist and timed out with "Connection closed by UNKNOWN port 65535". Root cause: Ansible only auto-discovers host_vars from directories co-located with the inventory file. The fork layout has .local/inventory/hosts.yml (discovered) but .local/host_vars/ (NOT discovered because it is parallel, not child). Fix: when generate_inventory.py is invoked with --host-vars-overlay (overlay mode), it now also writes the merged host_vars to <out_dir>/host_vars/proxmox-host.yml — so a typical `.local/inventory/hosts.yml` output also produces `.local/inventory/host_vars/proxmox-host.yml`. Ansible then sees the fork's proxmox_guests wholesale, and Stage 4 provisions guests in the correct subnet from the start. Net effect: `PLATFORM_IDENTITY_OVERLAY=<path> make generate-inventory` is now a single self-contained emission; no manual symlink or copy into .local/inventory/host_vars/ is needed. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com> * fix(proxmox_guests): preserve firewall flag in --net0; wait for SSH after cloud-init update proxmox_guests : Apply guest hardware and cloud-init settings was setting --net0 without the firewall= flag, stripping the firewall=0 that proxmox_network had just applied. This caused pve-firewall to re-evaluate the per-VM policy on the next cycle, which triggered a brief NIC hot-reconfigure that raced with the first guest play's Gathering Facts. Two fixes: 1. Carry `firewall=0/1` (from proxmox_firewall_enabled) through --net0 so proxmox_guests never strips what proxmox_network set. 2. Add a wait_for SSH check after the cloud-init update step so the role guarantees all guests are SSH-reachable before the proxmox-host play ends and Ansible transitions to the first guest play. Root cause of Stage 5 runs #4-#6 all failing at nginx UNREACHABLE. Ref: ws-0424-fork-clone-0fork, ws_0424_fresh_host_bootstrap_fixes. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.7 <noreply@anthropic.com>
baditaflorin
force-pushed
the
main
branch
10 times, most recently
from
a4c58b0 to
d8e6b32
Compare
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.
Bumps pytest from 8.4.2 to 9.0.3.
Release notes
Sourced from pytest's releases.
... (truncated)
Commits
a7d58d7Prepare release version 9.0.3089d981Merge pull request #14366 from bluetech/revert-14193-backport8127eafRevert "Fix: assertrepr_compare respects dict insertion order (#14050) (#14193)"99a7e60Merge pull request #14363 from pytest-dev/patchback/backports/9.0.x/95d8423bd...ddee02aMerge pull request #14343 from bluetech/cve-2025-71176-simple74eac69doc: Update training info (#14298) (#14301)f92dee7Merge pull request #14267 from pytest-dev/patchback/backports/9.0.x/d6fa26c62...7ee58acMerge pull request #12378 from Pierre-Sassoulas/fix-implicit-str-concat-and-d...37da870Merge pull request #14259 from mitre88/patch-4 (#14268)c34bfa3Add explanation for string context diffs (#14257) (#14266)Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting
@dependabot rebase.Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR:
@dependabot rebasewill rebase this PR@dependabot recreatewill recreate this PR, overwriting any edits that have been made to it@dependabot show <dependency name> ignore conditionswill show all of the ignore conditions of the specified dependency@dependabot ignore this major versionwill close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this minor versionwill close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this dependencywill close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)You can disable automated security fix PRs for this repo from the Security Alerts page.