Introduce Shared YAML Dependency File To Manage Replace Directives#4862
Introduce Shared YAML Dependency File To Manage Replace Directives#4862
Conversation
4095548 to
4eed3b6
Compare
92c493d to
903bfcc
Compare
a28eeea to
2fd651c
Compare
4691655 to
843ea22
Compare
🔍 Dependency ReviewNo dependency version changes detected in go.mod.
As a result, there are no dependency upgrades to analyze and no code changes required at this time. Notes
|
|
Thanks for the review so far @kgeckhart!
Exactly, it won't do the generation itself but it will fail if it detects that the output of the generation command does not match the existing state
Yes, technically a user could put replace manually inside the If a user adds or edits a replace directive manually within the template boundaries though, the CI will fail |
3a41a88 to
2600ab5
Compare
thampiotr
left a comment
There was a problem hiding this comment.
Just a few minor comments, but once resolved I think this is ready.
Co-authored-by: Piotr <17101802+thampiotr@users.noreply.github.com>
Co-authored-by: Kyle Eckhart <kgeckhart@users.noreply.github.com>
08e3bb2 to
1388c11
Compare
…roperly in workflow and use git diff instead so we can ignore whitespace changes
…rafana#4862) * Introduce new dependency management tool * Move syntax replace to top of go.mod to avoid confusion * Apply replaces from tool * Introduce PR workflow to check modules are synced * Add E2E test * Address some PR comments Co-authored-by: Piotr <17101802+thampiotr@users.noreply.github.com> * Refactor to use a centralised cobra CLI, called by generate.go * Refactor to not generate .txt files and pass replace text in memory * Refactor E2E tests to use explicit test data * Update tools/generate-module-dependencies/replaces-mod.tpl Co-authored-by: Kyle Eckhart <kgeckhart@users.noreply.github.com> * Return errors in FileHelper instead of using Fatalf * Address PR comments * go mod/mod changes * Reference actual calculated file to dependency yaml file in error logs * Group the generate-module-dependencies and Check for go.mod changes properly in workflow and use git diff instead so we can ignore whitespace changes * nit: a few improvements for clarity --------- Co-authored-by: Piotr <17101802+thampiotr@users.noreply.github.com> Co-authored-by: Kyle Eckhart <kgeckhart@users.noreply.github.com>
…rafana#4862) * Introduce new dependency management tool * Move syntax replace to top of go.mod to avoid confusion * Apply replaces from tool * Introduce PR workflow to check modules are synced * Add E2E test * Address some PR comments Co-authored-by: Piotr <17101802+thampiotr@users.noreply.github.com> * Refactor to use a centralised cobra CLI, called by generate.go * Refactor to not generate .txt files and pass replace text in memory * Refactor E2E tests to use explicit test data * Update tools/generate-module-dependencies/replaces-mod.tpl Co-authored-by: Kyle Eckhart <kgeckhart@users.noreply.github.com> * Return errors in FileHelper instead of using Fatalf * Address PR comments * go mod/mod changes * Reference actual calculated file to dependency yaml file in error logs * Group the generate-module-dependencies and Check for go.mod changes properly in workflow and use git diff instead so we can ignore whitespace changes * nit: a few improvements for clarity --------- Co-authored-by: Piotr <17101802+thampiotr@users.noreply.github.com> Co-authored-by: Kyle Eckhart <kgeckhart@users.noreply.github.com>
Part of #4719
This is an initial implementation taken from the PoC for Proposal 2 from this design doc
What is included
generate-module-dependenciestool in the Alloy project that can be run withmake generate-module-dependenciesdependency-replacements.yamlfile located at the root of the project, transform the data, and apply it to the maingo.modfile for Alloy. Note that for the time being this YAML file should not contain local replacements (e.g. we are not including thesyntaxmodule in that file in this PR)go.mod, but it is formatting them a bit due to the generation template being structuredmake generate-module-dependenciesand check that nothing is changed in thego.modfile in pipelines, this is to ensure that the state between the YAML replacements andgo.modfile(s) are alignedWhat is the intention
What will be done as follow ups
go.modfile generation, notocbyaml files - the latter will be introduced in a follow up PR. I've tried to keep things as "simple" as possible for now