Bump filippo.io/edwards25519 from 1.1.0 to 1.1.1 in /example in the go_modules group across 1 directory#32
Closed
dependabot[bot] wants to merge 1 commit intomainfrom
Conversation
Bumps the go_modules group with 1 update in the /example directory: [filippo.io/edwards25519](https://github.com/FiloSottile/edwards25519). Updates `filippo.io/edwards25519` from 1.1.0 to 1.1.1 - [Commits](FiloSottile/edwards25519@v1.1.0...v1.1.1) --- updated-dependencies: - dependency-name: filippo.io/edwards25519 dependency-version: 1.1.1 dependency-type: indirect dependency-group: go_modules ... Signed-off-by: dependabot[bot] <support@github.com>
dependabot
Bot
added
dependencies
Contributor
Author
|
None of your dependencies match this group anymore, you may need to update your configuration file to remove it or change its rules. |
dependabot
Bot
deleted the
dependabot/go_modules/example/go_modules-d60cbccd5d
branch
5 tasks
intel352
added a commit
that referenced
this pull request
Apr 23, 2026
… determinism, ResolveSizing, Close logging) (#472) * fix(config): ResolveForEnv lifts Config["name"] into ResolvedModule.Name When an env override sets a "name" key in Config, promote it to ResolvedModule.Name and delete it from Config. This ensures that ResourceSpec.Name carries the env-resolved name (e.g. "bmw-staging-vpc" instead of "bmw-vpc") so plan and apply agree on resource identity. Empty string is ignored to prevent accidental erasure of the module name. Closes follow-up #32. Tests: LiftsConfigNameIntoIdentity, PreservesNameWhenNoOverride, EmptyNameFieldIgnored. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com> * fix(platform): configHash sorts keys explicitly for determinism Use explicit sorted kv-pair encoding before SHA-256 so configHash produces the same value regardless of Go's randomised map-iteration order. Closes issue where successive applies without config changes produced spurious "update" plan actions. Add differ_hash_test.go (internal package) with stability test (100 iterations), empty-map sentinel, and inequality sanity check. Update hashConfig helper in differ_test.go to match the new encoding. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com> * fix(wfctl): invoke provider.ResolveSizing before plan for sized specs For each ResourceSpec with a non-empty Size field, call provider.ResolveSizing(type, size, hints) inside applyWithProviderAndStore before ComputePlan. The returned ProviderSizing.InstanceType and extra Specs are merged into spec.Config so that plan and apply agree on the concrete instance type (e.g. Size:"m" → instance_type:"s-1vcpu-2gb"). If the provider returns nil (no resolution needed), the spec is unchanged. Also aligns configHashMap in infra.go with platform.configHash: use sorted kv-pair encoding so ResourceState.ConfigHash values written during apply are comparable on the next run's ComputePlan. Tests: TestApplyInfraModules_CallsResolveSizing_ForEachSpec verifies ResolveSizing is called exactly once per sized spec and that spec.Config is enriched before Apply. Updated TestApplyWithProvider_NoChanges and TestApplyWithProvider_DeletesRemovedResource to use configHashMap(). Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com> * fix(wfctl): log provider Close() errors as stderr warnings Replace `defer closer.Close() //nolint:errcheck` with an explicit defer that writes `warning: provider %q shutdown: %v` to stderr in four files: - cmd/wfctl/infra_apply.go - cmd/wfctl/infra_destroy.go - cmd/wfctl/infra_status_drift.go (two closures: status + drift) - cmd/wfctl/infra_bootstrap.go Plugin subprocess leaks now surface instead of being silently discarded. Test: TestApplyWithProvider_LogsCloseError injects an error-producing io.Closer via resolveIaCProvider override, redirects os.Stderr via os.Pipe, and asserts that the warning message appears in captured output. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com> * test(wfctl): plan-vs-apply equivalence test harness Add infra_plan_apply_equivalence_test.go with recordingProvider and TestPlanApplyEquivalence_EnvOverrideNames — the regression gate for Bug #32 and the class of env-override name divergences: 1. Build a BMW-shaped infra.yaml with env overrides that rename every resource (bmw-vpc → bmw-staging-vpc, etc.). 2. Call planResourcesForEnv("staging") — capture intended names. 3. Call applyInfraModules with a recording fake provider that captures actual spec.Name values passed to Apply. 4. Assert the two name sets are identical. Also add TestPlanResourcesForEnv_UsesEnvOverrideNames to infra_env_wire_test.go — unit-level assertion that planResourcesForEnv returns env-override names, not raw module names. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com> * chore: CHANGELOG v0.18.7 — plan/apply equivalence Document the five fixes: ResolveForEnv name lift, configHash determinism, ResolveSizing invocation, Close() error logging, and the plan-vs-apply equivalence test harness. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com> * fix(test): update configHashIntegration to sorted kv encoding configHashIntegration in module/infra_module_integration_test.go was using the old json.Marshal(map) hash format, producing a different hash than platform.configHash (which uses sorted kv-pairs). This caused TestInfraModule_DriftDetectionFlow to emit a spurious "update" action and fail. Updated to match the platform canonical encoding exactly. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com> * fix(lint): eliminate G602 and guard ResolveSizing on abstract sizes only Two related fixes to the ResolveSizing loop in applyWithProviderAndStore: 1. G602 (gosec slice index out-of-range false positive): replace indexing via specs[i] with a local pointer `spec := &specs[i]` so gosec can confirm the slice access is safe. 2. isAbstractSize guard (Copilot #2): add isAbstractSize helper that returns true only for xs/s/m/l/xl. ResolveSizing is now skipped for provider-specific slugs (e.g. "db-s-1vcpu-1gb") which are already concrete and must not be re-resolved. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com> * fix(config): scope ResolveForEnv name-lift to infra.* modules only The env-override name lift in ResolveForEnv previously applied to all module types. This was too broad — non-infra modules can legitimately carry a 'name' key in their Config for display purposes. Added strings.HasPrefix(resolved.Type, "infra.") guard so only infra.* modules have their Config["name"] lifted into ResolvedModule.Name. All other module types are unaffected. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com> * fix(test): add t.Cleanup for stderr restore in LogsCloseError test TestApplyWithProvider_LogsCloseError redirects os.Stderr but did not register a cleanup handler. If the test failed early (e.g. at os.Pipe), stderr would remain redirected for subsequent tests. Added t.Cleanup that restores oldStderr and closes both pipe ends, guaranteeing the redirect is always undone regardless of test outcome. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com> * refactor: export platform.ConfigHash and delegate from configHashMap configHashMap in cmd/wfctl/infra.go duplicated the sorted kv-pair encoding logic from platform.configHash. Any future change to the hashing algorithm would require updating two places. Added exported platform.ConfigHash wrapper that delegates to the package-internal configHash function. configHashMap now delegates to platform.ConfigHash, eliminating the duplication and ensuring the two are always byte-for-byte identical. Removed now-unused crypto/sha256 and sort imports from infra.go. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com> --------- Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
intel352
added a commit
that referenced
this pull request
Apr 24, 2026
Refactored resolveModCfg closure in deploy_providers.go to return *config.ResolvedModule so callers see both resolved.Name (env-override lifted from Config["name"]) and resolved.Config. All three call sites (iac.provider lookup, findByType, fallback loop) now read resolved.Name instead of m.Name. Same class as v0.18.7 Task #32 fix for ResourceSpec.Name — env override of Config["name"] was lifted into ResolvedModule.Name but deploy_providers.go read m.Name directly, ignoring the override. Caused BMW deploy run 24888583717 to create duplicate DO apps (bmw-app vs bmw-staging). Regression tested via: - TestPluginDeployProvider_UsesEnvResolvedName (new, was failing) - TestPluginDeployProvider_FallsBackToModuleNameWhenNoEnv (new, baseline) Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
intel352
added a commit
that referenced
this pull request
Apr 24, 2026
…nfra_output (#476) * docs: v0.19.0 architectural cleanup design — plugin manifest, multi-registry, typed gRPC args, migrate image, teardown Five features bundled into v0.19.0 for shared config-file shape (wfctl.yaml + .wfctl-lock.yaml) and release boundary. Each addresses architectural debt surfaced during BMW tonight's deploy blocker chain. Features: - A. Plugin manifest + lockfile split (tasks #42/#43) - B. Multi-registry + IaCProvider.EnsureRegistryAuth (task #48) - C. Typed-args refactor for IaCProvider gRPC (task #41) - D. Official workflow-migrate Docker image (task #49) - E. wfctl infra teardown with mandatory dry-run + --approve flag (new) Non-goals: constraint-based plugin resolution (v0.20.0), transitive plugin deps, OCI chart/artifact registries, cross-registry mirroring. Autonomous pipeline target: v0.19.0 after BMW post-teardown stabilizes. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * docs: v0.19.0 design — add Features F, G, H (outputs, verify, secret sinks) Scope expanded from 5 to 7 features per user feedback on BMW CI gap audit: - F. wfctl infra outputs with masked-by-default sensitivity + GHA ::add-mask:: - G. wfctl deploy verify with multi-target healthcheck + retry/timeout gate - H. Declarative secret sinks (outputs.<field>.sinks[]) — plaintext never leaves wfctl process; built-in github_secret + github_env handlers; aws/gcp/azure sinks via plugin fan-out in v0.19.x Motivation: BMW's Capture staging DB URL step uses doctl + awk + gh secret set shell pipeline, leaking DATABASE_URL plaintext through stdout/env/argv. Declarative sink pattern (like terraform's output-to-secret-manager) writes the value in-process directly to the GitHub secrets API with libsodium encryption. Matches user's stated principle: "if BMW CI has provider-specific shell, fix it in workflow/wfctl so the CI stays declarative." Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * docs: v0.19.0 implementation plan — 7 features × 9 phases Matches design doc 2026-04-24-v0.19.0-architectural-cleanup-design.md: - Phase 1 alpha.1: Feature A (plugin manifest + lockfile) - Phase 2 alpha.2: Feature C client-side (typed gRPC args) - Phase 3 (DO plugin v0.8.0): Feature C server-side + integration tests - Phase 4 alpha.3: Feature B (multi-registry) - Phase 5 (DO plugin v0.8.1): Feature B server-side (EnsureRegistryAuth) - Phase 6a rc1: Feature D (workflow-migrate image) - Phase 6b rc2: Feature E (wfctl infra teardown) - Phase 6c rc3: Features F + G + H (outputs + verify + sinks) - Phase 7: v0.19.0 final + changelog + docs - Phase 8: Plugin fan-out (aws/gcp/azure/tofu) in parallel - Phase 9: BMW migration PR (after v0.19.0 stabilizes) Timing: all phases can merge independently; final v0.19.0 tag and Phase 9 hold until BMW's tonight deploy chain reaches prod /healthz green (task #26). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * docs: address PR #474 review — reconcile feature count, flag naming, source task column * docs: v0.18.9 phase-continuation design — env-resolution consistency BMW deploy run 24888583717 created a duplicate DO App Platform app because wfctl infra apply used env-resolved name "bmw-staging" while wfctl ci run --phase deploy used base module name "bmw-app". Both paths call driver.Read by name; with different names they find different resources (or none) and each calls Create, producing duplicates. Root cause: cmd/wfctl/deploy_providers.go:769 reads m.Name directly after ResolveForEnv has been applied. Same class as v0.18.7's Task #32 fix but in the deploy-phase code path. Fix: refactor resolveModCfg closure to return *ResolvedModule, use resolved.Name at call sites. Audit + patch infra_output source resolution (task #56) with the same pattern. Ship as v0.18.9. Does not require state-sharing between IaC and CI phases; the bug is about names, not state. Both phases use driver.Read by name; aligning the names aligns the lookups. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * docs: v0.18.9 phase-continuation implementation plan 9 tasks across Phase 1 (core fixes: deploy_providers.go + infra_secrets.go + regression tests) and Phase 2 (release + BMW unblock: PR, merge, tag, BMW bump, teardown, redeploy). Same-class fix as v0.18.7 Task #32: env-resolved Name used consistently wherever modules are consumed. Target: v0.18.9 hotfix; unblocks BMW staging deploy from run 24888583717 duplicate-resource failure. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * fix(wfctl): ci run deploy uses env-resolved module name (not base) Refactored resolveModCfg closure in deploy_providers.go to return *config.ResolvedModule so callers see both resolved.Name (env-override lifted from Config["name"]) and resolved.Config. All three call sites (iac.provider lookup, findByType, fallback loop) now read resolved.Name instead of m.Name. Same class as v0.18.7 Task #32 fix for ResourceSpec.Name — env override of Config["name"] was lifted into ResolvedModule.Name but deploy_providers.go read m.Name directly, ignoring the override. Caused BMW deploy run 24888583717 to create duplicate DO apps (bmw-app vs bmw-staging). Regression tested via: - TestPluginDeployProvider_UsesEnvResolvedName (new, was failing) - TestPluginDeployProvider_FallsBackToModuleNameWhenNoEnv (new, baseline) Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com> * fix(wfctl): infra_output source module name flows through env resolution Introduces resolveInfraOutput(wfCfg, source, envName, stateOutputs) which translates the base module name in a "module.field" source string to its env-resolved name before looking up state. State is persisted under the env-resolved name (e.g. "bmw-staging-db"), so "bmw-database.uri" with --env staging now correctly finds the state entry. syncInfraOutputSecrets now accepts wfCfg and envName so the new resolution is applied for every infra_output secret in the generate list. The call site in infra.go (runInfraApply) loads the workflow config and passes it through. Closes task #56. Regression tested via: - TestInfraOutput_EnvResolvesModuleSource (new, was failing) - TestInfraOutput_NoEnvUsesBaseName (new, baseline) Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com> * docs: CHANGELOG v0.18.9 entry Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com> * fix(wfctl): stateKeys actually sorts keys (comment matched implementation) Agent-Logs-Url: https://github.com/GoCodeAlone/workflow/sessions/a0429849-a053-4485-914d-ccb115be94e8 Co-authored-by: intel352 <77607+intel352@users.noreply.github.com> * fix(wfctl): address 4 Copilot round-1 findings on v0.18.9 (#476) - resolveInfraOutput: ResolveForEnv ok=false now errors (config error) instead of silently falling back to base module name — prevents the env-resolution fix from being bypassed on misconfigured envs - stateKeys: add sort.Strings so error messages list available modules in deterministic order (comment already said "sorted") - infra.go: surface config.LoadFromFile error instead of discarding it — silent failure would regress env resolution to the pre-fix nil-wfCfg path - CHANGELOG: replace "Closes task #60" (ambiguous GitHub issue ref) with "Root cause from BMW deploy run 24888583717" Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com> * fix(wfctl): accurate error message + test for explicitly-disabled module in resolveInfraOutput Agent-Logs-Url: https://github.com/GoCodeAlone/workflow/sessions/3accbfdf-259b-4b98-a44e-8b538d3f5857 Co-authored-by: intel352 <77607+intel352@users.noreply.github.com> * fix(wfctl): gate LoadFromFile on envName + infra_output presence (#476) Skip config.LoadFromFile when env resolution is not needed: - envName="" → no env resolution, wfCfg=nil is correct - no infra_output generators → syncInfraOutputSecrets ignores wfCfg Avoids unnecessary file I/O on every infra apply when the caller has no infra_output secrets or is not running with --env. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com> Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com> Co-authored-by: intel352 <77607+intel352@users.noreply.github.com>
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 the go_modules group with 1 update in the /example directory: filippo.io/edwards25519.
Updates
filippo.io/edwards25519from 1.1.0 to 1.1.1Commits
d1c650aextra: initialize receiver in MultiScalarMultDependabot 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 <dependency name> major versionwill close this group update PR and stop Dependabot creating any more for the specific dependency's major version (unless you unignore this specific dependency's major version or upgrade to it yourself)@dependabot ignore <dependency name> minor versionwill close this group update PR and stop Dependabot creating any more for the specific dependency's minor version (unless you unignore this specific dependency's minor version or upgrade to it yourself)@dependabot ignore <dependency name>will close this group update PR and stop Dependabot creating any more for the specific dependency (unless you unignore this specific dependency or upgrade to it yourself)@dependabot unignore <dependency name>will remove all of the ignore conditions of the specified dependency@dependabot unignore <dependency name> <ignore condition>will remove the ignore condition of the specified dependency and ignore conditionsYou can disable automated security fix PRs for this repo from the Security Alerts page.