Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

hugo: module fails `dagger functions` lint — OTel version skew in generated internal/telemetry client

Closed
  • Is something wrong?
#294 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
3/5
Estimated time
1-2 days
Newbie friendliness
55/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Quiet
Tech stack
go
Domain
build-system, devops

Research direction

Start in hugo/internal/telemetry/transform.go and hugo/go.mod, then reproduce the failure with go build ./... from hugo/. Compare the generated telemetry API with the resolved OpenTelemetry versions and choose the consistent regeneration or dependency-alignment path. Done means the build passes and dagger functions (hugo) lint is green.

Written by the indexing model from the issue text.

Description

bug

Problem

The hugo module does not compile: its checked-in generated client hugo/internal/telemetry/transform.go was generated against an older OpenTelemetry SDK, but hugo/go.mod now resolves a newer go.opentelemetry.io/otel/sdk/log. The interface signatures no longer match.

go build ./... in hugo/:

# dagger/hugo/internal/telemetry
internal/telemetry/transform.go:69:29: cannot use res (variable of type *resource.Resource) as resource.Resource value in argument to ResourceToPB
internal/telemetry/transform.go:957:25: cannot use processor (variable of type *collectLogProcessor) as "go.opentelemetry.io/otel/sdk/log".Processor value in argument to sdklog.WithProcessor: *collectLogProcessor does not implement "go.opentelemetry.io/otel/sdk/log".Processor (wrong type for method Enabled)
        have Enabled(context.Context, "go.opentelemetry.io/otel/sdk/log".Record) bool
        want Enabled(context.Context, "go.opentelemetry.io/otel/sdk/log".EnabledParameters) bool
internal/telemetry/transform.go:999:26: cannot use (*collectLogProcessor)(nil) ... (same Enabled mismatch)

i.e. the generated collectLogProcessor implements the old Enabled(ctx, Record) signature, while the resolved otel/sdk/log interface wants Enabled(ctx, EnabledParameters).

Why it's not visible on main

The dagger functions (hugo) CI job only runs when the hugo module changes (gated by the "Detect changed modules" job). Since hugo hasn't been touched, the broken build never runs on main. It surfaced while pinning base images (#288 follow-up): a one-line change to hugo/merge.go triggered the hugo lint job, which failed on the pre-existing breakage — see PR #293, where the hugo change was dropped to keep the PR green.

Reproduce

cd hugo
go build ./...   # fails as above

Notes / attempted fix

  • dagger develop in hugo/ only updated go.mod/go.sum (engine already at the pinned v0.20.8) and did not regenerate internal/telemetry, so the build still fails.
  • hugo/go.mod has replace directives pinning the otlplog / otel/sdk/log / otel/log libs to v0.16.0, but the require block lists v0.17.0 — this version skew is the likely root cause; the generated code targets one and the resolved graph the other.

Suggested fix (one of)

  1. Regenerate the hugo internal client against an engine whose generated telemetry matches the resolved otel/sdk/log API.
  2. Align hugo/go.mod — make the otel/sdk/log (+ related otlplog / otel/log) require versions and the replace directives consistent so collectLogProcessor.Enabled matches the resolved interface.

Acceptance

  • go build ./... passes in hugo/.
  • dagger functions (hugo) lint is green.
  • Follow-up: the deferred hugo/merge.go base-image pin (alpine:latest -> alpine:3.21, see #288) can then land.

Context

  • Surfaced by #288 / PR #293.
  • Same From("alpine:latest") pinning is still pending in hugo/merge.go, blocked on this.
Dominant language
Go
Stars
3
Forks
0
Avg merge
21h 53m
Merged PRs (30d)
26

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from stuttgart-things/dagger

All issues in stuttgart-things/dagger

Similar issues

More Go issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.