Further improvements to personal access token handling
We are adding the ability to create personal access tokens (PAT) via the API when an admin token is available in this MR: gitlab-org/gitlab!53739 (merged)
This issue lists two more potential improvements to the handling of PAT that could improve the test suite's runtime even further:
1. Add ability to cache personal access tokens by username
Currently, we cache the Runtime::API::Client
and hence the personal access token (PAT) for each resource in the QA::Resource::ApiFabricator
module. This means that a new token will be created for each resource created by a user. This issue is to enable caching of PAT with a PersonaAccessTokenCache
class. The cache will hold a hash of username as key and PAT as the value.
This cache will be used by QA::Resource::PersonalAccessToken
to return the PAT if available for the user.
This should also help address the last point from this issue:
On GitLab.com where we do not have admin access, use existing PATs for existing users. Do not create new PATs via the UI.
.admin?
check
2. Fix In gitlab-org/gitlab!53739 (merged), we added the ability to use the API to create a PAT if an admin's PAT is available. The mechanism uses a call to .admin?
to identify and admin and store its token as such. However, many certain cases, a user such as root
, although an admin, returns false
to the call of .admin?
because the user was created with Resource::User.new.tap
. In such cases, we can potentially call .reload!
on the resource so that the resource's attributes are populated and the call to .admin?
returns the correct value.
We would need to investigate the correct place to add reload!
. Incorrect placement could potentially lead to a loop as reload!
uses api_get
that also requires a PAT.