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.
# 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
metadata(Attributes) (see below for nested schema)
Optional
spec(Attributes) Spec contains the resource configuration. (see below for nested schema)
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:
terraform import almaforge_jira_connector.jira jiraterraform planUse 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.