[migueldalberto]

Why

The QoR dashboard wants a "my branches / my builds" view. The only identity it has today is the commit's git author, fetched best-effort from GitHub. That misses builds a user started by hand on someone else's commit, and commits enrichment never reaches.

What

Two optional flags on flow/util/uploadMetadata.py:

Flag	Payload key	Jenkins source
--buildUserEmail	build_user_email	BUILD_USER_EMAIL — user who started the build by hand
--changeAuthorEmail	change_author_email	CHANGE_AUTHOR_EMAIL — PR author on PR builds

• Sent at the top level on every schema version, including the v1 per-design fallback.
• Blank values are left out.
• They describe the build, not the payload's shape, so payload_schema_version is unchanged.
• Without the flags the payload is byte-for-byte what it was.

jenkins-ci passes them from orfsUploadMetadata, probing for --buildUserEmail support like it does for --provenanceFile, so older ORFS branches keep uploading.

[gemini-code-assist]

Code Review

This pull request adds support for capturing build requester information by introducing --buildUserEmail and --changeAuthorEmail command-line arguments to uploadMetadata.py. It includes a helper function resolve_requester to parse and clean these fields, which are then added to the pipeline and per-design payloads. The review feedback suggests two valuable improvements: simplifying the resolve_requester function using a dictionary comprehension for cleaner code, and hoisting the resolve_requester call outside the loop in publish_v1_per_design to prevent redundant executions and improve performance.

[openroad-ci]

🔍 QoR check

Metrics reflect the PR merge build — i.e. what will land on the target branch.

Commit 471ab74 · Jenkins build #9 · Baseline: build · View build on dashboard

62 design(s) checked — 0 with regression(s), 0 without a comparable baseline.

[vvbandeira]

Thanks. With no flags the payload does not change, and the code looks correct. Some items before merge:

1. Tests. Please add tests through build_pipeline_payload and publish_v1_per_design: both flags set, one blank or whitespace-only, and both absent. The last case must prove that the payload is the same as before this PR.
2. Linked changes. Please link the backend change that reads build_user_email / change_author_email and the jenkins-ci orfsUploadMetadata change, so we can check the key names and the case where a key is absent.
3. Value check. resolve_requester (line 224) accepts any non-blank string. An unset Groovy variable gives the string "null", which would be stored as an email. Please treat null/None as blank, or require an @.
4. Console log. A Jenkins sh step prints its command with -x, so --buildUserEmail <addr> puts the Jenkins user's email in the build log. Could the script read BUILD_USER_EMAIL / CHANGE_AUTHOR_EMAIL from the environment instead, or could the caller use set +x?
5. Data access. BUILD_USER_EMAIL can be a private address. Who can read the Pub/Sub topic and the dashboard?
6. Nit: in publish_v1_per_design, payload.update(requester) runs before payload.update(d["metrics"]), so a metric with the same name would replace it. A comment, or applying the requester keys last, would make this clear.

Heads-up: #4646 conflicts in two places with this PR, so the second one to merge will need a rebase.

[migueldalberto]

Thanks for the review. I pushed fixes in four commits.

1. Tests. flow/test/test_uploadMetadata.py runs the script against a stub publisher and covers both flags set, one blank, and both absent, on the pipeline payload and on the v1 fallback messages. The absent case compares the whole payload, so it shows a build without the flags publishes what it did before.
2. Linked changes. The consumer of build_user_email / change_author_email and the Jenkins library change live in private repositories, so I can't link them here. The consumer reads both keys by presence and treats a missing key as "no requester". I'll share the key names and a sample payload with you directly.
3. Value check. A value without an @ is now dropped with a warning, so the "null" from an unset Groovy variable is never stored. The requester is resolved once and passed to both payload builders, so the warning prints once on the v1 fallback.
4. Console log. When a flag is absent, the script reads UPLOAD_BUILD_USER_EMAIL / UPLOAD_CHANGE_AUTHOR_EMAIL. An empty flag suppresses the variable. The Jenkins library already exports those names. It still passes the flags today, so the address would reach the log. A follow-up there will stop passing them.
5. Data access. Only the CI publisher, the consuming service and infrastructure administrators can read the topic. The stored emails are not returned by any API response. They are used server-side to decide whose builds an author filter matches. One open point: that filter is reachable without signing in, so someone who guesses an address can tell whether builds are attributed to it. I'm raising that separately.
6. Nit. In the v1 messages the requester keys are now applied after the metrics. A test covers a metric with the same name.

Also fixed merge conflicts.

[vvbandeira]

approved from devops team side