build(deps): bump actions/cache from 4 to 5#2
Closed
dependabot[bot] wants to merge 1 commit into
Closed
Conversation
Bumps [actions/cache](https://github.com/actions/cache) from 4 to 5. - [Release notes](https://github.com/actions/cache/releases) - [Changelog](https://github.com/actions/cache/blob/main/RELEASES.md) - [Commits](actions/cache@v4...v5) --- updated-dependencies: - dependency-name: actions/cache dependency-version: '5' dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <support@github.com>
Contributor
Author
LabelsThe following labels could not be found: Please fix the above issues or remove invalid values from |
Contributor
Author
|
Looks like actions/cache is up-to-date now, so this is no longer needed. |
16 tasks
emeraldleaf
added a commit
that referenced
this pull request
May 23, 2026
CodeRabbit (PR #17) flagged that the "in-flight PR" phrasing goes stale the moment this PR merges. Reword to describe the configured state (upload is in ci.yml) and the pending event (badge reflects aggregate after the next green CI run), not the temporal state of this PR. Addresses CodeRabbit finding #2 of 2 on the PR. Finding #1 (pin codecov-action to commit SHA) deferred — would create inconsistency with the other six actions in the same workflow (actions/checkout@v6, actions/setup-dotnet@v5, actions/cache@v5, dorny/test-reporter@v3, github/codeql-action/*@v4, plus the two codecov-action calls), all of which use version-pinned mutable tags by existing repo convention. If we want SHA-pinning, it's a workflow-wide hardening pass, not a one-off here. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
emeraldleaf
added a commit
that referenced
this pull request
May 28, 2026
Three small edits: 1. CodeRabbit #1 (full-saga-deployment-plan.md:335): the "Related docs" pointer said STATUS.md references this doc "under 'Open issues'" but the entry actually lives under "Next." Fixed to match. 2. CodeRabbit #2 (STATUS.md:103): the "Next" entry still said "four open decisions (D1-D4) block Phase 1" but the plan doc now lists D1-D4 as resolved 2026-05-27. Updated to reflect resolved state + name the chosen options + point at Phase 1A as the next concrete work. 3. Seq named as the Phase 3 telemetry choice. Sourced from an article on structured logging + distributed tracing for microservices with Seq. Seq fits this deployment shape better than App Insights — unified logs + traces in one UI, self-hostable on Fly with persistent volume (matches D2 Keycloak pattern), free tier covers demo scope, OTLP-native (slots into existing OpenTelemetry export with one config-line change). Gotcha captured: pin OpenTelemetry.Instrumentation.* packages explicitly in Directory.Packages.props, since non-stable RC versions for instrumentations like StackExchangeRedis differ across major bumps. No new rule encoding — the article reinforces existing CLAUDE.md rules (structured logging with message templates, OpenTelemetry instrumentation patterns) without adding net-new lessons worth encoding. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
emeraldleaf
added a commit
that referenced
this pull request
May 28, 2026
* plan(deploy): add full-saga demo deployment plan + STATUS pointer
Cross-session tracking artifact for the multi-PR, multi-week effort to
stand up NextAurora as a portfolio-grade demo deployment running the
full Order → Payment → Shipping → Notification saga over real cloud
infrastructure with the Stripe gateway stubbed.
Structure:
- Three phases, each independently shippable:
1. Order saga visible (Catalog + Order + minimal Storefront). Order
persists, OrderPlacedEvent stages, saga stalls because PaymentService
isn't deployed yet — itself a teaching demo.
2. Full saga (Payment + Shipping + Notification). End-to-end flow over
real infrastructure with stubbed Stripe.
3. Polish (observability + ops + minimal UX) — demoable to humans.
- Four open decisions (D1-D4) called out explicitly: SQL Server hosting,
identity provider, messaging transport, cost ceiling. All block Phase 1.
- Out-of-scope explicitly listed: real Stripe SDK (stub retirement),
PaymentRecoveryJob retry-with-key (gated on stub retirement),
production-grade DR/SLAs. Honest framing of what this is and isn't.
- Cost ledger structure ready for first entries once provisioning begins.
STATUS.md "Next" section now points at the plan so future sessions
can pick up coherently.
Following the IDSD/intent-driven discipline encoded in the recent
articles: explicit intent + expectations + context as a tracked
artifact BEFORE implementation, not after. The plan is the "ICE"
artifact for this multi-PR effort.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
* plan(deploy): resolve D1-D4 decisions + split Phase 1 into 1A + 1B
User-resolved decisions captured in the plan doc:
- D1 (SQL Server hosting): Postgres-only-for-demo with provider swap.
Dev environment keeps two-engine split (the architectural story is
still genuine for dev/learning). Deployed environment uses Postgres
for all four services with state. README footnote will explain the
demo-deployment exception.
- D2 (Identity): Auth0 free tier. Hosted, simplest setup. Keycloak
stays for local dev. ServiceDefaults JWT config is already
config-driven — points at Auth0 issuer in deployed environment.
- D3 (Messaging): AWS SQS+SNS free tier. Wolverine reconfig from
UseAzureServiceBus to UseAmazonSqs. 1M req/mo free covers demo
volume comfortably.
- D4 (Cost ceiling): $30/mo target, $50/mo hard ceiling. Phase 1 ≤$15,
Phase 2 ≤$30. Fly.io spend cap to be set at $50 before any
provisioning.
Phase 1 now splits naturally into two sub-PRs given D1:
- Phase 1A: Postgres provider swap (code only). Add `DatabaseProvider`
config setting, branch Order + Payment Program.cs on it, regenerate
Postgres migrations, branch concurrency-token config (RowVersion vs
xmin). Integration tests cover both paths. README footnote.
- Phase 1B: Deploy Order + minimal Storefront. Original Phase 1 goal,
now sitting on top of 1A's plumbing.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
* plan(deploy): switch D2 to Keycloak self-hosted + restructure Phase 1 + Phase 3 rate-limit audit
User reconsidered D2 after seeing an article on Keycloak's value as an
identity provider. Switched from Auth0 to Keycloak self-hosted on Fly.
Rationale:
- Same IdP in dev and prod. NextAurora already runs Keycloak in local
Aspire dev with the realm at realms/nextaurora-realm.json. Deployed
Keycloak imports the same realm export on boot — one IdP, one realm,
two environments. Removes "works in dev, breaks in prod" risk around
realm shape, claim names, test users.
- Stronger portfolio story than vendor-managed Auth0.
- Cost is roughly comparable (~$5-10/mo Fly Machine vs Auth0 free
vendor-locked).
Trade-off: real ops surface (Postgres DB for Keycloak state, persistent
volume, realm-import-on-boot, two-stage readiness probe, ~30-60s cold
start for Java + realm import).
Phase 1 now splits into three sub-PRs:
- 1A: Postgres provider swap (code only) — unchanged
- 1B: Deploy Keycloak self-hosted (NEW infrastructure-only sub-phase)
- 1C: Deploy Order + minimal Storefront against deployed Keycloak
Phase 3 deliverables grown by one item: rate-limit audit + Redis-backed
swap if any service runs 2+ Fly Machines. The in-memory ASP.NET Core
limiter on Catalog search + Payment process is correct for single-
instance Phase 2 but silently weakens under scale-out. The rule
encoding lands in a separate PR (CLAUDE.md / .coderabbit.yaml /
architecture-reviewer.md).
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
* plan(deploy): CodeRabbit review fixes + Seq for Phase 3 telemetry
Three small edits:
1. CodeRabbit #1 (full-saga-deployment-plan.md:335): the "Related docs"
pointer said STATUS.md references this doc "under 'Open issues'" but
the entry actually lives under "Next." Fixed to match.
2. CodeRabbit #2 (STATUS.md:103): the "Next" entry still said "four open
decisions (D1-D4) block Phase 1" but the plan doc now lists D1-D4 as
resolved 2026-05-27. Updated to reflect resolved state + name the
chosen options + point at Phase 1A as the next concrete work.
3. Seq named as the Phase 3 telemetry choice. Sourced from an article on
structured logging + distributed tracing for microservices with Seq.
Seq fits this deployment shape better than App Insights — unified logs
+ traces in one UI, self-hostable on Fly with persistent volume
(matches D2 Keycloak pattern), free tier covers demo scope, OTLP-native
(slots into existing OpenTelemetry export with one config-line change).
Gotcha captured: pin OpenTelemetry.Instrumentation.* packages
explicitly in Directory.Packages.props, since non-stable RC versions
for instrumentations like StackExchangeRedis differ across major
bumps.
No new rule encoding — the article reinforces existing CLAUDE.md rules
(structured logging with message templates, OpenTelemetry instrumentation
patterns) without adding net-new lessons worth encoding.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 4.7 <noreply@anthropic.com>
3 tasks
emeraldleaf
added a commit
that referenced
this pull request
May 31, 2026
…ment spectrum + tier skills honestly (#54) dev-loop.md drifted since the simplicity refactor (May 2026). Refresh pulls the Continuous Rule Encoding loop up to be the centerpiece — it's the project's distinguishing characteristic but was buried at the bottom of the doc — and adds the architectural surfaces that have shipped since. Structural changes: - Pulled "Continuous Rule Encoding" up to load-bearing section 2 (was buried after Stage 5). Enumerated the six surfaces with a "Catches violations at..." column, named the encoding threshold, documented the cross-reference convention (`See CLAUDE.md.`) and the two mechanical enforcers. - Added "Enforcement spectrum" H2: convention → architecture tests → project split. NetArchTest (commit 8cba0d4) gives VSA the dependency-rule guarantee that Clean's project split would give, without the four-project ceremony. Includes the Promotion Signal table from CLAUDE.md verbatim. - Added "Loop comparison: spec-driven vs rule-encoding" — 7-row side-by-side table plus honest takeaway. Names Spec Kit, Kiro, AGENT.md, OpenAPI-first, TDD-as-spec as the spec-driven lineage; CLAUDE.md plays the AGENT.md role here. Explicit anti-recommendation: grafting Spec Kit mechanics would convert the compounding speed advantage into ceremony. - Added Gap 9 (distributed rate-limiting) and Gap 10 (`/specify-saga` skill — the one spec-driven element worth keeping in mind, but explicitly don't build yet). Stage updates: - Stage 3 now shows four integration slices (Catalog/Order/Payment/ Shipping) instead of two — Payment + Shipping landed in PRs from this session. - Stage 3 gained "Required-test patterns" sub-section: AAA narrative comments, IDOR test required, outbox-non-handler test, handler-DI- registration check. Each links the reference template from CLAUDE.md "Testing." - Stage 3 lists Wolverine.Tracking as test tooling (used by the new integration projects to settle async cascades before assertion). - Stage 4 adds a `.coderabbit.yaml path_instructions` sub-section describing the glob set as encoding surface #2 of the rule loop. - Stage 1 stops describing CLAUDE.md as "25 KB" (stale + no longer true) and stops describing AwesomeAssertions migration as a currency signal (the migration is done). Skills tiering (the load-bearing honesty pass): - Skills table reframed into three tiers — Actively used / Ambient (discipline absorbed into CLAUDE.md) / Dormant by design — instead of one "when it fires" column that implied uniform usage. Closes the same overclaim trap the doc itself criticizes. `dotnet- performance` called out as the only project-authored skill. - .claude/README.md skills inventory updated to match: same tier framing, plus a "trigger phrase" column that names the specific catch-yourself moment (the word "should," two failed bug attempts, "I just fixed one — are there more?", etc.) so the skill is reachable in the moment, not just listed abstractly. "The meta- pattern" callout at the bottom lists the five highest-signal trigger phrases for fast lookup during work. Co-authored-by: Claude Opus 4.7 <noreply@anthropic.com>
4 tasks
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
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 actions/cache from 4 to 5.
Release notes
Sourced from actions/cache's releases.
... (truncated)
Changelog
Sourced from actions/cache's changelog.
... (truncated)
Commits
27d5ce7Merge pull request #1747 from actions/yacaovsnc/update-dependencyf280785licensed changes619aeb1npm run build generated dist filesbcf16c2Update ts-http-runtime to 0.3.56682284Merge pull request #1738 from actions/prepare-v5.0.4e340396Update RELEASES8a67110Add licenses1865903Update dependencies & patch security vulnerabilities5656298Merge pull request #1722 from RyPeck/patch-14e380d1Fix cache key in examples.md for bun.lockDependabot 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)