Skip to main content

Configuration Overview

The JPD to GitHub Connector is configured through a YAML file that controls sync behavior, field mappings, status workflows, and more.

Configuration File Location​

By default, the connector looks for configuration at:

config/sync-config.yaml

You can specify a custom location using an environment variable:

CONFIG_PATH=./my-custom-config.yaml pnpm run dev

Configuration File Structure​

A configuration file has seven main sections:

# 1. JPD Project Settings
jpd:
project_key: "MTT"

# 2. GitHub Repository Settings
github:
owner: "expedition"
repo: "my-repo"

# 3. Sync Direction
sync:
direction: "bidirectional"

# 4. Field Definitions
fields:
priority:
field_id: "customfield_10001"
field_type: "select"

# 5. Field Mappings
mappings:
- jpd: "fields.priority.value"
github: "labels"

# 6. Status Workflows
statuses:
"To Do":
github_state: "open"

# 7. Label Definitions
labels:
hierarchy:
- name: "epic"
color: "0052CC"

Environment Variables​

Credentials are stored in a .env file (never commit this):

# JPD Authentication
JPD_BASE_URL=https://your-company.atlassian.net
JPD_EMAIL=your-email@company.com
JPD_API_KEY=your_api_token

# GitHub Authentication
GITHUB_TOKEN=ghp_your_github_token
GITHUB_OWNER=your-org
GITHUB_REPO=your-repo

# Optional Overrides
CONFIG_PATH=./config/sync-config.yaml
DEBUG=false

Variable Descriptions​

JPD_BASE_URL

  • Your Atlassian instance URL
  • Must include https://
  • Example: https://acme-corp.atlassian.net

JPD_EMAIL

  • Email for your Atlassian account
  • Used for Basic Authentication

JPD_API_KEY

GITHUB_TOKEN

  • Personal access token from GitHub
  • Generate at: GitHub Tokens
  • Required scopes: repo, optionally write:discussion

GITHUB_OWNER

  • GitHub username or organization name
  • Case-sensitive

GITHUB_REPO

  • Repository name (not full URL)
  • Case-sensitive

CONFIG_PATH (optional)

  • Override default config file location
  • Defaults to ./config/sync-config.yaml

DEBUG (optional)

  • Enable verbose logging
  • Set to true or 1

Configuration Validation​

Always validate your configuration before running a sync:

pnpm run validate-config

Validation checks:

  • YAML syntax is correct
  • Required fields are present
  • Environment variables are set
  • JPD field IDs exist
  • Field types match expectations
  • Status names are valid

Configuration Examples​

Minimal Configuration​

The absolute minimum needed to sync:

jpd:
project_key: "PROJ"

github:
owner: "my-org"
repo: "my-repo"

statuses:
"To Do":
github_state: "open"
"Done":
github_state: "closed"

A good starting configuration:

jpd:
project_key: "PROJ"

github:
owner: "my-org"
repo: "my-repo"

sync:
direction: "bidirectional"

fields:
priority:
field_id: "customfield_10001"
field_type: "select"
required: false

mappings:
- jpd: "fields.summary"
github: "title"
template: "[{{fields.project.key}}-{{fields.id | idonly}}] {{fields.summary}}"

- jpd: "fields.priority.value"
github: "labels"
template: "priority:{{fields.priority.value | lowercase}}"

statuses:
"To Do":
github_state: "open"
"In Progress":
github_state: "open"
"Done":
github_state: "closed"

labels:
hierarchy:
- name: "epic"
color: "0052CC"
description: "High-level initiative"

See config/mtt-clean.yaml in the repository for a complete example with:

  • Custom field validation
  • Transform functions
  • Hierarchy configuration
  • GitHub Projects integration
  • Comment sync settings
  • Rate limiting configuration

Configuration Sections​

Each section has its own detailed documentation page:

Core Settings​

JPD project, GitHub repository, and sync direction configuration.

Field Mappings​

Map JPD custom fields to GitHub issue properties and labels.

Status Workflows​

Define how statuses sync between JPD and GitHub.

Labels​

Configure automatic label creation with colors and descriptions.

Hierarchy​

Set up Epic > Story > Task relationships using statuses.

Advanced Configuration​

Transform functions, templates, rate limiting, and GitHub Projects.

Common Configuration Tasks​

Adding a New Field Mapping​

  1. Discover the field ID:

    pnpm run discover-fields YOUR_PROJECT
  2. Add to fields section:

    fields:
    my_field:
    field_id: "customfield_10005"
    field_type: "number"
    required: false
  3. Add to mappings section:

    mappings:
    - jpd: "fields.customfield_10005"
    github: "labels"
    template: "impact:{{fields.customfield_10005}}"
  4. Validate:

    pnpm run validate-config

Changing Status Mappings​

Edit the statuses section:

statuses:
"Your JPD Status":
github_state: "open" # or "closed"

Status names must match exactly (case-sensitive).

Adding New Labels​

Add to the labels section:

labels:
your_category:
- name: "label-name"
color: "FF5630" # Hex color (no #)
description: "Label description"

Labels are automatically created in GitHub if they don't exist.

Multiple Configurations​

Different Projects​

Create one config per project:

config/
project-a.yaml
project-b.yaml

Use with:

CONFIG_PATH=./config/project-b.yaml pnpm run dev

Environment-Specific Configs​

Separate configs for dev/staging/production:

config/
dev.yaml
staging.yaml
production.yaml

Pair with environment-specific .env files:

.env.development
.env.staging
.env.production

Troubleshooting Configuration​

"Configuration file not found"​

Check:

  • File exists at specified path
  • File name is correct (case-sensitive)
  • Using correct CONFIG_PATH if overriding

"Invalid YAML syntax"​

Check:

  • Proper indentation (use spaces, not tabs)
  • Colons followed by spaces
  • Quoted strings with special characters
  • Matching brackets and quotes

"Field validation failed"​

Check:

  • Field ID matches output from discover-fields
  • Field type is correct
  • Field actually exists in JPD
  • You have permission to access the field

"Status not found"​

Check:

  • Status name matches JPD exactly (case-sensitive)
  • No extra spaces before/after status name
  • Status exists in your JPD workflow

Next Steps​

Now that you understand the configuration structure:

Configuration Best Practices
  • Start with minimal config and add complexity gradually
  • Always run validate-config after changes
  • Test with --dry-run before actual sync
  • Keep multiple configs in version control (without credentials)
  • Document custom transform functions