GroupServiceAccountAccessTokenArgs

The gitlab.GroupServiceAccountAccessToken resource allows to manage the lifecycle of a group service account access token.

Use of the timestamp() function with expires_at will cause the resource to be re-created with every apply, it's recommended to use plantimestamp() or a static value instead. Reading the access token status of a service account requires an admin token or a top-level group owner token on gitlab.com. As a result, this resource will ignore permission errors when attempting to read the token status, and will rely on the values in state instead. This can lead to apply-time failures if the token configured for the provider doesn't have permissions to rotate tokens for the service account. Use rotation_configuration to automatically rotate tokens instead of using timestamp() as timestamp will cause changes with every plan. pulumi up must still be run to rotate the token. Due to a limitation in the API, the rotation_configuration is unable to set the new expiry date before GitLab 17.9. Instead, when the resource is created, it will default the expiry date to 7 days in the future. On each subsequent apply, the new expiry will be 7 days from the date of the apply. Upstream API: GitLab API docs

Import

Starting in Terraform v1.5.0 you can use an import block to import gitlab_group_service_account_access_token. For example: terraform import { to = gitlab_group_service_account_access_token.example id = "see CLI command below for ID" } Import using the CLI is supported using the following syntax:

$ pulumi import gitlab:index/groupServiceAccountAccessToken:GroupServiceAccountAccessToken You can import a service account access token using `<resource> <id>`. The

id is in the form of :: Importing an access token does not import the access token value.

$ pulumi import gitlab:index/groupServiceAccountAccessToken:GroupServiceAccountAccessToken example 1:2:3