Fix queue_duration metric to use queued_at instead of created_at

[Copilot]

GitHub support confirmed created_at is not the correct timestamp for measuring runner wait time — queued_at is when the job was actually placed in the runner queue. The previous formula (started_at - created_at) overstates queue duration.

Overview

Replace created_at with queued_at in the queue_duration calculation:

# Before
queue_duration = (job_info.started_at - job_info.created_at).total_seconds()

# After
queue_duration = (job_info.started_at - job_info.queued_at).total_seconds()

Rationale

Per GitHub support, queued_at is the timestamp when a job enters the runner queue. created_at precedes this and inflates the metric. The GitHub REST API (/repos/{owner}/{repo}/actions/runs/{run_id}/jobs) returns queued_at per job and is the documented way to measure runner wait time.

Juju Events Changes

None.

Module Changes

• types_/github.py: Added queued_at: datetime to the JobInfo pydantic model.
• platform/platform_provider.py: Added queued_at: datetime to the JobInfo dataclass.
• github_client.py: _to_job_info() now extracts queued_at from the API response.
• platform/github_provider.py: get_job_info() passes queued_at through to platform_provider.JobInfo.
• metrics/github.py: queue_duration now computed as started_at - queued_at.

Library Changes

None.

Checklist

• The charm style guide was applied.
• The contributing guide was applied.
• The changes are compliant with ISD054 - Managing Charm Complexity
• The documentation for charmhub is updated.
• The PR is tagged with appropriate label (urgent, trivial, complex).
• The changelog is updated with changes that affects the users of the charm.
• The application version number is updated in github-runner-manager/pyproject.toml.

---

🔒 GitHub Advanced Security automatically protects Copilot coding agent pull requests. You can protect all pull requests by enabling Advanced Security for your repositories. Learn more about Advanced Security.

[yhaliaw]

Good catch.

One question to clarify things.

[yhaliaw]

Is this a fail safe in case queued_at is missing?
Is it often that queued_at is missing?

[yanksyoon]

Yup, it's a failsafe - the field queued_at exists for job_info for all the jobs but is null from all the API responses that I've tested. I'm not entirely sure when it gets set to null and when it has a set value (the documentation does not exist), but this should set us back to the original behavior.

[yanksyoon]

Quick GitHub API verification with list jobs & runs returns payload with queued_at field set to null. Enquired GitHub support again.