Skip to content

Ambiguous Documentation for Importing sentry_organization_repository: Clarification Needed on internal_id #624

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
abdolnabi opened this issue Apr 8, 2025 · 0 comments

Comments

@abdolnabi
Copy link

abdolnabi commented Apr 8, 2025

Description:
While attempting to import resources using the sentry_organization_repository resource, I encountered unclear documentation and inconsistencies in variable naming which made the process challenging. The current documentation instructs the use of the following command for importing:

terraform import sentry_organization_repository.this org-slug/integration-type/integration-id/internal-id

However, it is unclear what internal_id refers to, as there is no mention of it in the data retrieved from the Sentry API.

API Response Example:

{
  "id": "xxxxx",
  "name": "teamname/projectname",
  "url": "urladdress",
  "provider": {
    "id": "integrations:gitlab",
    "name": "Gitlab"
  },
  "status": "active",
  "dateCreated": "xxxx-xx-xxTxx:xx:xx.Z",
  "integrationId": "xxxxx",
  "externalSlug": "xxxxxxxx",
  "externalId": "gitlab.com:xxxxxx"
}

From this response, it's apparent that there is no key corresponding to internal_id. Attempting to use the id for import as internal_id resulted in a warning about resource destruction due to mismatches between id and identifier. Further investigation revealed that externalSlug is effectively being used as what the import command describes as internal_id.

Issue:
The main issues are:

  1. Lack of clarity about what constitutes internal_id in the import command.
  2. Inconsistency in naming conventions between the documentation and what is retrieved from the Sentry API.

This has led to confusion and potential errors during the import process.

Proposed Solution:
I suggest updating the documentation to clearly define what internal_id is supposed to reference, with a direct mapping to the data obtainable through the Sentry API. A potential update could explicitly state that internal_id corresponds to the externalSlug, if that is indeed the case.

Steps to Reproduce:

  1. Attempt to import a sentry_organization_repository using the current documentation's import command format.
  2. Note the absence of internal_id in the Sentry API response.
  3. Observe warnings or errors when using other IDs (such as id or externalId) as internal_id.

Expected Outcome:
The documentation should clearly map all components of the import command to retrievable data from the Sentry API, ensuring a smooth and error-free import process.

Additional Context:

Successfully completing the import using externalSlug as internal_id suggests a discrepancy between implementation and documentation. This needs to be aligned to avoid user confusion and potential data management errors.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant