[builder] Support for --skip-new-go-module #9631
Conversation
kristinapathak
force-pushed
the
builder-skip-module
branch
from
f8c34f5 to
b8030d3
Compare
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #9631 +/- ##
==========================================
- Coverage 91.34% 90.71% -0.63%
==========================================
Files 357 353 -4
Lines 19196 18773 -423
==========================================
- Hits 17534 17030 -504
- Misses 1334 1403 +69
- Partials 328 340 +12 ☔ View full report in Codecov by Sentry. |
kristinapathak
force-pushed
the
builder-skip-module
branch
3 times, most recently
from
9240936 to
efce7a9
Compare
kristinapathak
force-pushed
the
builder-skip-module
branch
from
304e97e to
b7d0161
Compare
|
This PR was marked stale due to lack of activity. It will be closed in 14 days. |
|
Discussed at the collector sig meeting today - I will look into splitting up the strict versioning and skip new go module flag additions into their own PRs. |
Please ping me directly once you have them ready, I'll review the PRs. |
cmd/builder/README.md
Outdated
| ### Strict versioning checks | ||
|
|
||
| There is an option that controls version strictness applied by the | ||
| builder. When the `--strict-versioning` command-line flag is used, | ||
| the following additional checks apply to the finished `go.mod` file | ||
| after getting all the components and tidying the result. | ||
|
|
||
| 1. The `dist::otelcol_version` field in the build configuration must | ||
| match the core library version calculated by the Go toolchain, | ||
| considering all components. A mismatch could happen, for example, | ||
| when one of the components depends on a newer release of the core | ||
| collector library. | ||
| 2. For each component in the build configuration, the version included | ||
| in the `gomod` module specifier must match the one calculated by | ||
| the Go toolchain, considering all components. A mismatch could | ||
| happen, for example, when the enclosing Go module uses a newer | ||
| release of the core collector library. |
There was a problem hiding this comment.
I think this should be the default, and would have prevented issues such as #8692. Let's do this on a separate PR, I am happy to review that one :)
kristinapathak
force-pushed
the
builder-skip-module
branch
from
8585de4 to
7a11360
Compare
kristinapathak
force-pushed
the
builder-skip-module
branch
from
7a11360 to
cedc4bc
Compare
|
This PR was marked stale due to lack of activity. It will be closed in 14 days. |
|
I'll be rebasing this and adding tests tonight. |
|
Declaring PR bankruptcy and trying again here. |
A continuation of #9253 and #9631 Description: Adds a `--skip-new-go-module` flag to the OTC builder. This enables users working in an existing go module environment (say, a "monorepo") to update the module they have, vs forcing the use of a new module. With the new support inside an existing Go module, a collector main package can be generated using a go:generate directive. For example, in the directory where I want my collector built, the file generate.go has this line: //go:generate builder --skip-new-go-module --skip-compilation --strict-versioning --config=./build-config.yaml In the same directory, the build-config.yaml describes the collector to build. The builder generates the other files in the same directory. At this point, normal Go workflows can be used to update indirect dependencies. Link to tracking Issue: #9252 Testing: Will add unit tests in the next few days. Documentation: Yes. --------- Co-authored-by: Pablo Baeyens <pbaeyens31+github@gmail.com>
A continuation of #9253
Description: Adds a --skip-new-go-module flag to the OTC builder. This enables users working in an existing go module environment (say, a "monorepo") to update the module they have, vs forcing the use of a new module.
With the new support inside an existing Go module, a collector main package can be generated using a go:generate directive. For example, in the directory where I want my collector built, the file generate.go has this line:
//go:generate builder --skip-new-go-module --skip-compilation --strict-versioning --config=./build-config.yaml
In the same directory, the build-config.yaml describes the collector to build. The builder generates the other files in the same directory. At this point, normal Go workflows can be used to update indirect dependencies. The optional --strict-versioning checks that the build configuration matches that resulting from the enclosing Go module.
Link to tracking Issue: #9252
Testing: Unit tests added.
Documentation: Yes.