https://linen.dev logo
Join Slack
Powered by
Hi! I can update connector versions via API: PUT...
# replication-ask-ai
l
Hi! I can update connector versions via API: PUT /workspaces/{workspace}/definitions/sources/{definitionId} { "name": "Jira", "dockerImageTag": "4.3.16" } I tried importing the existing JIRA source definition and managing it with Terraform:
Copy code
import {
    to = airbyte_source_definition.jira[0]
    id = jsonencode({
      id = ".."
      workspace_id = "your-workspace-id"
    })
  }
resource "airbyte_source_definition" "jira_definition" {

  name              = "Jira"
  docker_repository = "airbyte/source-jira"
  docker_image_tag  = "4.3.17"

}
What's the recommended way to manage connector version updates through Terraform? @kapa.ai
k
Great question! The approach you're using with 
airbyte_source_definition
is designed for custom connectors (Docker-based), not for managing versions of Airbyte's built-in catalog connectors like Jira. Recommended Approach (Provider 1.0+) The recommended way to manage connector versions in Terraform is to use the generic 
airbyte_source
resource combined with the 
airbyte_connector_configuration
data source, which supports version pinning via 
connector_version
. [Migrating to 1.0] Here's how to pin the Jira source to a specific version:
Copy code
data "airbyte_connector_configuration" "jira" {
  connector_name    = "source-jira"
  connector_version = "4.3.17"  # pin to a specific version

  configuration = {
    # your Jira connection config here
  }

  configuration_secrets = {
    # sensitive values here
  }
}

resource "airbyte_source" "jira" {
  name          = "Jira"
  workspace_id  = var.workspace_id
  definition_id = data.airbyte_connector_configuration.jira.definition_id
  configuration = data.airbyte_connector_configuration.jira.configuration_json
}
This approach provides: [connector_configuration data source] ā€¢ Automatic 
definition_id
resolution from the connector name (no need to hardcode it) ā€¢ Version pinning via 
connector_version
ā€¢ Config validation against the connector's JSONSchema at 
terraform plan
time ā€¢ Clean diffs by separating sensitive and non-sensitive values About airbyte_source_definition The 
airbyte_source_definition
resource is intended for custom Docker-based connectors (i.e., connectors you build yourself), not for Airbyte's built-in catalog connectors like Jira. [source_definition resource] Note on Typed Resources If you were previously using 
airbyte_source_jira
, note that typed connector-specific resources are deprecated as of provider 1.0 and targeted for removal in 1.1. Migrating to the generic 
airbyte_source
resource is strongly recommended. [Migrating to 1.0] šŸ‘ 0 button šŸ‘Ž 0 button ā„¹ļø Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.
l
When I used the airbyte_connector_configuration to create a resource pinned to an older version (not the latest) it created the airbyte_source with the latest version. Is that expected behaviour? @kapa.ai
k
The knowledge sources do not contain enough information to definitively explain why the 
airbyte_source
resource would be created with the latest version instead of the pinned version specified in 
connector_version
. What the documentation does confirm is that the 
connector_version
parameter in 
airbyte_connector_configuration
is intended to pin to a specific version: [connector_configuration data source] > "The version of the connector (e.g. 
2.0.0
). If not specified, the latest version is used. When set, the connector spec for that exact version is fetched and used for JSONSchema validation." So based on the documentation, pinning to an older version via 
connector_version
should work as expected ā€” it is not documented as expected behaviour that the latest version would be used when a specific version is set. This could potentially be a bug in the Terraform provider. I'd recommend: 1. Double-checking that 
connector_version
is correctly set in your 
airbyte_connector_configuration
data source and that the data source output is actually being used by the 
airbyte_source
resource. 2. Checking the 
docker_image_tag
output from the data source (a read-only attribute) to verify which version was resolved. 3. If the issue persists, consider opening a GitHub issue in the Airbyte Terraform provider repository with a reproducible example. šŸ‘ 0 button šŸ‘Ž 0 button ā„¹ļø Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.
2 Views
Open in Slack
PreviousNext
Powered by