2052175 - Ensure reproducibility with metric date expires by using SOURCE_DATE_EPOCH when set

Status: RESOLVED FIXED

(Data Platform and Tools :: Glean: SDK, enhancement, P1)

Description

[Pier Angelo Vendrame]

glean_parser checks if a metric is expired at build time by comparing its expires with datetime.datetime.now() in glean_parser/util.py.
This contributes to break the reproducibility of the builds.
It would be nice to be able to set an environment variable like SOURCE_DATE_EPOCH and use it instead of now when defined.
This would be helpful for us downstream at The Tor Project ☺️.

Comment 1

[Jan-Erik Rediger [:janerik]]

All metrics in the Firefox source tree should check expiry against a version number, not against the date.
Can you point out where in the current build that breaks?

Regardless the problem might still be worth fixing for other code.

Comment 2

[Pier Angelo Vendrame]

I found the problem in Glean 67.3.1.
glean-core/metrics.yaml there contains:

  event_timestamp_clamped:
    type: counter
    description: |
      The number of times we had to clamp an event timestamp
      for exceeding the range of a signed 64-bit integer (9223372036854775807).
    send_in_pings:
      - health
    bugs:
      - https://bugzilla.mozilla.org/show_bug.cgi?id=1873482
    data_reviews:
      - https://bugzilla.mozilla.org/show_bug.cgi?id=1873482
    data_sensitivity:
      - technical
    notification_emails:
      - [e-mail]
      - [e-mail]
    expires: 2026-06-30

In the glean-67.3.1-sources.jar file that is generated, I can see GleanError.kt:

/*
 * AUTOGENERATED BY glean_parser v19.0.0. DO NOT EDIT. DO NOT COMMIT.
 */

// ...

    @get:JvmName("eventTimestampClamped")
    val eventTimestampClamped: CounterMetricType by lazy { // generated from glean.error.event_timestamp_clamped
        CounterMetricType(
            CommonMetricData(
                category = "glean.error",
                name = "event_timestamp_clamped",
                sendInPings = listOf("health"),
                lifetime = Lifetime.PING,
                disabled = false
            ))
    }

I built it before yesterday, and I got disabled = false. But a colleague of mine who built yesterday got disabled = true, and that ended up in the final APKs.

Comment 3

[Jan-Erik Rediger [:janerik]]

Ah, yes. That's in Glean itself, so that of course breaks when building Glean from source at a later point (we should probably switch that to version expiry too).
Supporting SOURCE_DATE_EPOCH should be possible.

Comment 4

[BMO Github Automation]

Attachment: [mozilla/glean_parser] Bug 2052175 - Support `SOURCE_DATE_EPOCH` to use as the date to check expiry against (#851)

Comment 5

[Jan-Erik Rediger [:janerik]]

badboy merged PR [mozilla/glean_parser]: Bug 2052175 - Support SOURCE_DATE_EPOCH to use as the date to check expiry against (#851Edit title) in 3fd422d.

---

I'll probably cut a release this week.