test(e2e): reuse config.TrunkConfig in the harness Config#422
Merged
Conversation
The single-step and multi-step scenario harness carried a hand-mirrored Config struct that duplicated trunk-config.yaml by hand. Any manifest field nobody remembered to copy across was silently dropped on marshal, so a new generator feature needed a matching harness edit before a scenario could reach it. Alias the harness Config to config.TrunkConfig, the CLI's own manifest type, so every field the CLI parses is marshalable into a scenario's manifest.yaml with no parallel struct to maintain. The multi-repo path already carried config.TrunkConfig directly; single-step and multi-step now match it. The two harness call sites that read changelog and validate as generic maps switch to the typed pointer fields. Add regression coverage proving a field absent from the retired struct (tag_prefix) now round-trips from a scenario into the generated ci.config block without a harness change. Signed-off-by: Joshua Temple <joshua.temple@stablekernel.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
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.
What
Closes #386. The e2e harness carried a hand-maintained Config struct duplicating the manifest schema; unmirrored fields were silently dropped on marshal (the #414 hand-added Inputs/Components were the symptom).
Change
Configis now a type alias:type Config = config.TrunkConfig(the CLI's authoritative manifest type). Every field the CLI parses is automatically marshalable into a scenario's manifest.yaml, with no parallel struct to maintain. This mirrors the multi-repo path (multi_repo_scenario.go), which already used config.TrunkConfig. Deleted the orphaned harness-local Config/BuildConfig/DeployConfig/PublishConfig/ConcurrencySpec.Byte-compatibility
config.TrunkConfig is the CLI's own parse type, so harness marshal then CLI parse is a faithful round-trip. The one behavioral delta: the old struct emitted empty builds: []/depends_on: [] (no omitempty); the typed type omits them, which the CLI parses to the same value. Validated across scenarios (see below); the full e2e matrix on this PR exercises all 80+.
Tests
Verification
go build (main + e2e), go test (main 2289 pass; harness unit 4 pass), golangci-lint, e2e build+vet all clean; Docker e2e (Custom Changelog + Two Env Happy Path) green. This PR relies on the full e2e matrix to confirm no scenario regresses from the omitempty delta.