Release Notes¶

v0.3.1-31¶

Added a centralised, opt-in logging framework (gerrit_to_platform._logging) that operators can configure via G2P_LOG_* environment variables or a new [logging] section in gerrit_to_platform.ini. Default behaviour is unchanged (WARNING to stderr).

Logging supports a human-readable text format and a one-object- per-line JSON format (schema_version "1") suitable for aggregation in Loki / ELK / GitHub Actions log artefacts.

Each hook invocation carries a short correlation id, attached to every log line as cid=…. The id can be inherited from a parent process (e.g. the gerrit-action hook wrapper) by setting correlation_id_env to the relevant env-var name.

Hook entry-points (patchset-created, comment-added, change-merged) and the find_and_dispatch lifecycle now emit structured hook=…, platform detected, workflow lookup, dispatch attempt, dispatch success/failure and hook=… exit elapsed_ms=… lines so operators can diagnose ephemeral container deployments (Docker, GitHub-CI sandboxes) without source access.

The GitHub client wrapper logs every workflow dispatch and workflows-list call with timing, owner/repo and outcome.

A RedactingFilter is attached to every handler installed by configure() and scrubs GitHub token shapes, Authorization headers, token= query-string parameters and labelled token=/secret=/password= values from log records before any handler sees them.

Added four annotated example workflows in examples/workflows/ demonstrating how to build Gerrit-integrated GitHub Actions workflows:
- github-vanilla-verify.yaml — Baseline GitHub workflow (no Gerrit)
- gerrit-verify.yaml — Gerrit verify pattern with vote lifecycle and checkout-gerrit-change-action
- gerrit-merge.yaml — Post-merge pattern using comment-only mode and standard actions/checkout
- gerrit-verify-manual-dispatch.yaml — Hybrid pattern supporting both Gerrit dispatch and manual runs from the GitHub Actions UI

No action is required for existing deployments: the framework is backwards-compatible at default verbosity. See docs/LOGGING.md for the new operator-facing configuration surface.

No operator action required. Existing deployments that did not trigger this crash (because their replication.config happened to keep fetch to a single line per remote) see no behaviour change. Deployments that did crash after every hook event — notably any pull-replication setup mirrored from a Gerrit source — will start dispatching workflows successfully after this release.

Behaviour for Gerrit servers that emit the legacy triplet shape is unchanged. Servers that emit the modern compact shape (Gerrit 3.x and later, or any older server configured to use the new shape) will start successfully dispatching workflows after this release; no operator action is required.

get_change_id now raises ValueError instead of IndexError for unrecognised input, which makes triage easier when inspecting hook tracebacks.

Fix configparser.DuplicateOptionError raised from every hook invocation when replication.config contains multi-valued fetch = ... refspecs under a single [remote "..."] section. This is the canonical shape Gerrit’s pull-replication plugin writes (and is valid git-config syntax for representing a list), but Python’s configparser defaults to strict=True and refuses to parse repeated keys. get_config() now constructs the parser with strict=False, which allows the multi-valued keys through with “last value wins” semantics. g2p only reads the single-valued url, authgroup and remotenamestyle keys from the remote sections, never the multi-valued fetch key, so the relaxed semantics have no functional impact.

Fix IndexError: list index out of range raised from every hook invocation against Gerrit 3.x servers that pass the modern compact --change argument (<URL-encoded project>~<number>, e.g. ccsdk%2Fapps~1). The previous get_change_id implementation only matched the legacy triplet form (project~branch~Iabc123...) and crashed for anything else, dropping every patchset-created, comment-added and change-merged event before workflow dispatch could run.

get_change_id now returns the legacy I... Change-Id when the legacy triplet form is supplied, and returns the modern compact project~number identifier verbatim otherwise. The compact form is still a unique, stable identifier per change and works as a GERRIT_CHANGE_ID workflow input (e.g. for concurrency.group keys).

Magic repos may not have the same branches that the source repo does make the assumption / requirement that the magic repo uses refs/heads/main for everything

Required workflows are now searched for out of the ORGANIZATION/.github magic repository which matches with ‘required’ as part of the workflow filename.

Only workflow files will be searched for relevant jobs to execute. They must now also contain ‘gerrit’ in the filename.

ex gerrit-verify.yaml or verify-gerrit.yaml instead of a verify.yaml

Workflow names (friendly name inside the workflow) are no longer searched for triggering purposes

This is the initial release of gerrit_to_platform.