Skip to main content

almaforge_jira_connector Resource

Manage an AlmaForge JiraConnector resource.

Before you start​

Use the Terraform setup guide to install the provider and sign in. Your identity needs permission to manage this resource. Keep one owner for each resource name, following the ownership rules.

Prepare a Jira bot account, API token, project, and issue type using the Jira prerequisites. The project's workflow needs the transitions described there. Use the exact resource name jira, which the built-in integration reads.

Terraform creates the connector, not the Jira project or workflow. Follow the Jira integration guide to test an access request end to end.

Example Usage​

Download main.tf into its own directory. Replace example values with your cluster and integration settings. Use the plan and apply workflow after preparing the prerequisites above.

Supply sensitive inputs from your secret manager or protected TF_VAR_ environment variables. Sensitive values are hidden in normal plan output but remain in saved plans and state. See connector secrets.

HCL
# Create access-request issues in a Jira project with the required workflow.
terraform {
required_providers {
almaforge = {
source = "get.almaforge.com/almaforge/almaforge"
}
}
}

provider "almaforge" {}

variable "api_token" {
type = string
description = "Jira API token. Supply through TF_VAR_api_token."
sensitive = true
}

resource "almaforge_jira_connector" "jira" {
metadata = {
name = "jira"
}
spec = {
url = "https://example.atlassian.net"
username = "[email protected]"
api_token = var.api_token
project = "ACCESS"
issue_type = "Task"
}
}

See the configuration reference for the resource manifest and field context.

Changes and deletion​

Configuration is authoritative. Removing an optional attribute resets its API default or clears it when no default exists. Changing metadata.name replaces the resource. Review the plan before applying. See lifecycle behavior.

Destroy deletes the connector. Check the linked integration guide's operations and removal sections before removing a connector that users or approval workflows depend on.

To read an existing object without managing it, use the named data source.

Schema​

Required​

Optional​

Nested Schema for metadata​

Required:

  • name (String) Resource name. Changing this name replaces the resource.

Optional:

  • labels (Map of String) Labels attached to the resource.

Read-Only:

  • resource_version (String) Server revision used to detect concurrent changes.

Nested Schema for spec​

Optional:

  • api_token (String, Sensitive) APIToken is the Jira API token. Accepts a literal value or a value-expansion reference such as "${file:/etc/jira/token}" or "${env:JIRA_API_TOKEN}".
  • issue_type (String) IssueType is the Jira issue type to create.
  • project (String) Project is the Jira project key under which access-request issues are created.
  • url (String) URL is the base URL of the Jira deployment, e.g. https://example.atlassian.net.
  • username (String) Username is the Jira account username (typically the user's email address) used to authenticate API calls.

Import​

Create the matching resource block first, then import the existing object's metadata.name. With the example above, the Terraform address and server name are:

Terminal
terraform import almaforge_jira_connector.jira jiraterraform plan

Use the address from your configuration and the name of the existing object. Import records the object in Terraform state. Review the first plan carefully because omitted fields will reset or clear on apply. The import guide also covers generating configuration from an existing object.

Supply the connector's current secret values before applying. The API redacts credentials on reads, so import cannot recover them. Configured secrets are preserved during subsequent refreshes.