fix(agent): use UTC when calculating token expiration
Description
- fix(agent): use UTC when calculating token expiration
The API documentation for managing user access tokens does not provide any clarity about how the expiration token is interpreted. However, the personal access token documentation indicates the token's expiration date is set to midnight UTC. This appears to be how the user access tokens API operates as well. Changing the CLI to match timezones resolves an issue where the CLI client could, depending on the host's timezone and time-of-day, request an expiration date in the past when interpeted as UTC (e.g. invoking glab cluster agent get-token at 23:00 America/Chicago on May 23rd causes the client to request a token using May 24th as the expiration date, even though May 24th 00:00 UTC has already passed). This would cause the token to be invalid for use by kubectl or any other API interactions.
Related Issues
Resolves #7799 (closed)
How has this been tested?
I am admittedly newer to testing golang code, and would be open to any advice if unit tests are appropriate for this change.
To test this change, I built a version of the cli client locally with no changes to verify the linked issue was still replicable, and a second version with the proposed change.
With the current main branch:
Running TZ=America/Chicago glab cluster agent get-token --agent <agent-id> at 04:00 UTC, the JSON response returned has a UTC timestamp that has already occurred (e.g. 2025-05-23T23:55:00Z).
Running TZ=UTC glab cluster agent get-token --agent <agent-id> at 04:00 UTC, the JSON response returned has a UTC timestamp in the future (e.g. 2025-05-24T23:55:00Z), which appears to be the desired functionality.
With this MR:
Running TZ=America/Chicago glab cluster agent get-token --agent <agent-id> at 04:00 UTC, the JSON response returned now has a future UTC timestamp (e.g. 2025-05-24T23:55:00Z), resolving the behavior described in the issue.
Running TZ=UTC glab cluster agent get-token --agent <agent-id> at 04:00 UTC, the JSON response returned has a UTC timestamp in the future (e.g. 2025-05-24T23:55:00Z), matching the previous functionality.
Screenshots (if appropriate):
Types of changes
-
Bug fix (non-breaking change which fixes an issue) -
New feature (non-breaking change which adds functionality) -
Breaking change (fix or feature that would cause existing functionality to change) -
Documentation -
Chore (Related to CI or Packaging to platforms) -
Test gap