chore(extension/alloyengine): Publish as independent Go module

[kgeckhart]

Brief description of Pull Request

Publishes extension/alloyengine as an independently versioned Go module so it can be referenced from external OpenTelemetry Collector Builder distros.

Pull Request Details

The extension/alloyengine module has its own go.mod but has never been tagged or tracked by release-please, making it impossible to reference from external OpenTelemetry Collector Builder distros.

This adds extension/alloyengine to release-please so it gets tagged alongside each Alloy release (e.g. extension/alloyengine/v1.15.0). It also updates the require for github.com/grafana/alloy from the sentinel version (v0.0.0-00010101000000-000000000000) to v1.15.0 so external consumers can resolve the transitive dependency from the module proxy — the existing replace directive continues to override this locally.

Finally, extension/alloyengine/go.mod is added to the root package's extra-files so the require version stays in sync with the Alloy version on each future release.

Issue(s) fixed by this Pull Request

Fixes #5823

Notes to the Reviewer

I'll create the extension/alloyengine/v1.15.0 tag manually after merging to backfill the current release. Future releases will be tagged automatically by release-please.

[github-actions]

🔍 Dependency Review

github.com/grafana/alloy v0.0.0-00010101000000-000000000000 -> v1.15.0 — ✅ Safe

Summary:

• This change pins a previously placeholder/self-reference of the same repository to a real, tagged version.
• In extension/alloyengine, a local replace continues to ensure the build uses the current local source tree, not a downloaded module; thus no API delta is introduced by this change.
• In collector, aligning to v1.15.0 establishes a valid semver tag for the same codebase you are developing in this repo. No code changes are required.

Why this is safe:

• The previous version v0.0.0-00010101000000-000000000000 is the canonical “zero” pseudo-version that is commonly used with a replace to local sources. It does not correspond to any upstream API surface; it resolves to the local checkout.
• The extension module still explicitly replaces to the local root:

  --- a/extension/alloyengine/go.mod
  +++ b/extension/alloyengine/go.mod
   replace github.com/grafana/alloy => ../..
   replace github.com/grafana/alloy/syntax => ../../syntax

  Therefore, the effective dependency remains your current working tree, meaning there is no functional upgrade in that module.
• For the collector module, switching from a non-existent pseudo-version to a proper tag in the same major version of this repo introduces no upstream API break and simply makes the dependency resolvable via Go modules.

Evidence (from the diff):

--- collector/go.mod
-require (
-   github.com/grafana/alloy v0.0.0-00010101000000-000000000000
+require (
+   github.com/grafana/alloy v1.15.0
    github.com/grafana/alloy/extension/alloyengine v0.1.0
    ...

Action needed:

• None. No code changes are required to adopt this version.

Suggested verification:

• Run:
  • go mod tidy
  • go build ./...
  • Project tests and any integration smoke tests

Notes

• The update also keeps a local replace in extension/alloyengine pointing at the repo root, so that submodule continues to consume local sources. No net-new external dependencies were introduced in the go.mod changes you provided.

[blewis12]

yay!

[jharvey10]

Even though we can version the alloyengine extension separately from base Alloy, I'd recommend we don't do that.

To me, it seems fair to have them always synchronized since the extension is pretty much just a wrapper around Alloy. The only potential "gotcha" with doing that is that if the extension's wrapper code itself needs an update (even if base Alloy doesn't need an update), we'd need to bump Alloy in order to do that as a BAU PR like for anything else Alloy-related.

Said differently: A merged change affecting just the alloyengine extension would create a normal changelog entry for base Alloy, which would get picked up as a change for the next "normal" Alloy release by the existing release-please process.

Given that approach, all we'd need to do is have a basic workflow which runs when new alloy release tags get published and reacts by pushing a corresponding tag for the extension, e.g. extension/alloyengine@v1.15.0.

The go.mod "sync" would be handled by release-please (via an "extra file") and the tagging would be a small workflow file. No separate release-please package needed. Since we're locally replacing the module, there's no go.sum update needed to go along with that either.

There's an extremely tiny gap between when the go.mod file gets updated with the new alloy version (when the PR gets merged) and when the tag actually gets created, but we're talking maybe 30 seconds, max, and none of the build artifacts would have started building until the tag exists anyway, so the risk is incredibly minimal.

[kgeckhart]

I think that's all fair, our goal wasn't really to have a process to release it independently so keeping it a post process makes sense. I updated the PR accordingly.