Problem
Attempts to create a GitLab.com or GitLab EE/CE VCS provider in the Terraform Enterprise UI fail with the following validation error.
Must be a 64-character alphanumeric string.
Prerequisites
- Terraform Enterprise versions prior to
v202310-1. - GitLab.com or GitLab EE/CE VCS provider.
Cause
In September 2023, GitLab changed its token format to include a prefix of gloas-, which increased the total character count from 64 to 70. Terraform Enterprise versions prior to v202310-1 contain a UI validation that enforces a 64-character limit for the client secret provided in the Secret field. This validation was updated in version v202310-1 to account for the new token format.
Solutions
The following workarounds are available for users on Terraform Enterprise releases prior to v202310-1.
Solution 1: Use the API or tfe Provider
You can create the VCS provider programmatically using the Create an OAuth Client API or the HashiCorp tfe provider. After creating the provider via the API, you must connect it in the Terraform Enterprise UI.
Below is an example payload for configuring OAuth authentication.
{
"data": {
"type": "oauth-clients",
"attributes": {
"service-provider": "gitlab_hosted",
"http-url": "https://gitlab.com",
"api-url": "https://gitlab.com/api/v4",
"key": "<GITLAB_APPLICATION_ID>",
"secret": "<GITLAB_APPLICATION_SECRET>"
}
}
}Alternatively, you can make the connection using a GitLab personal access token by providing it as the value for data.attributes.oauth-token-string.
Solution 2: Use a Partial Secret in the UI
You can bypass the initial validation in the UI with a two-step process.
- Create the VCS provider in the UI, but omit the
gloas-prefix from the secret and save the provider. - The initial OAuth authentication flow will fail. Edit the VCS provider again and enter the correct 70-character client secret, including the prefix.
The validation check does not run on updates, allowing you to save the correct secret. You can then manually connect the provider.