Skip to content

Bug: REST API hostname derived as gerrit.{org}.org instead of reading .gitreview host #157

@askb

Description

@askb

Bug Description

The Gerrit REST API hostname is derived as gerrit.{org}.org (line 488 in src/github2gerrit/config.py) instead of reading the host field from .gitreview. This causes REST API calls (used by cleanup steps) to fail when the Gerrit instance uses a different hostname convention.

Root Cause

In src/github2gerrit/config.py, line 488:

gerrit_host = configured_server or f"gerrit.{org}.org"

The SSH connection correctly reads .gitreview (e.g., host=git.opendaylight.org), but the REST API hostname falls back to gerrit.{organization}.org when GERRIT_SERVER is not explicitly set.

Impact

For OpenDaylight (opendaylight org), this constructs gerrit.opendaylight.org for REST API calls, but the actual Gerrit server is at git.opendaylight.org. The gerrit.opendaylight.org hostname is behind Cloudflare and is blocked/unreachable from GitHub Actions runners.

This causes the post-sync cleanup step to fail with:

requests.exceptions.ConnectionError: HTTPSConnectionPool(host='gerrit.opendaylight.org', port=443):
Max retries exceeded with url: /changes/?q=project:l2switch%20status:open&o=CURRENT_REVISION&o=CURRENT_COMMIT&n=100
(Caused by NameResolutionError("Failed to resolve 'gerrit.opendaylight.org' ([Errno -2] Name or service not known)"))

github2gerrit.gerrit_rest.GerritRestError: Gerrit REST GET https://gerrit.opendaylight.org/changes/... failed

The actual PR→Gerrit sync via SSH succeeds (using the correct git.opendaylight.org:29418), but the job is marked as failure because the cleanup REST call fails.

Affected Repos

All 17 OpenDaylight repositories using github2gerrit-action@v1.0.8:
aaa, bgpcep, controller, daexim, gnmi, ietf, infrautils, jsonrpc, l2switch, lispflowmapping, mdsal, netconf, odlparent, openflowplugin, ovsdb, transportpce, yangtools

Example Failure

.gitreview Content (all ODL repos)

[gerrit]
host=git.opendaylight.org
port=29418
project=<repo>.git
defaultbranch=master

Expected Behavior

The REST API hostname should be derived from the .gitreview host field (same as SSH), not constructed as gerrit.{org}.org. The .gitreview file is already parsed for SSH — the same host should be used for REST API calls.

Suggested Fix

In src/github2gerrit/config.py, read .gitreview host before falling back:

# Read from .gitreview if available
gitreview_host = _read_gitreview_host()  # parse [gerrit] host= from .gitreview
gerrit_host = configured_server or gitreview_host or f"gerrit.{org}.org"

Workaround

Explicitly pass GERRIT_SERVER input in the workflow:

- uses: lfreleng-actions/github2gerrit-action@de8477030c26a8020e9c95cd6312d5647392b347
  with:
    GERRIT_SERVER: "git.opendaylight.org"
    # ... other inputs

Secondary Issue

Additionally, the cleanup REST failure marks the entire job as failed even though the primary operation (PR→Gerrit sync) succeeded. Consider making cleanup failures non-fatal (warning instead of error) since the core functionality completed successfully.

Additional Issue: UPDATE fails for never-synced PRs on reopened event

When a PR is closed and reopened (triggering the reopened event), g2g treats it as an UPDATE operation. If the PR was never previously synced (e.g., because the g2g action was broken at the time), the UPDATE fails with:

UPDATE operation requires existing Gerrit change, but none found.
PR #3 should have an existing change with topic 'GH-opendaylight-aaa-3'.

The CREATE_MISSING input (default: false) exists to handle this, but it is not documented prominently and the error message does not mention it as a solution. Consider either:

  1. Defaulting CREATE_MISSING to true
  2. Adding CREATE_MISSING: true guidance to the error message

Environment

  • Action version: v1.0.8 (de8477030c26a8020e9c95cd6312d5647392b347)
  • Runner: ubuntu-24.04
  • Python: 3.14.3
  • Organization: opendaylight

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions