Guides
v1.0
Guides
Start typing to search…
  1. Guides
  2. Common Use Cases

Configuration Updates

Step-by-step guide for using Tidra to standardize configurations across repositories.

When to Use This

Configuration updates are ideal when you need to:

  • Standardize settings across services
  • Update config values organization-wide
  • Add new configuration sections
  • Migrate to new config formats
  • Ensure compliance with policies

Common examples:

  • CI/CD pipeline configs
  • Docker configurations
  • Infrastructure as code
  • Application config files
  • Build configurations

Basic Pattern

1. Identify What to Change

Be specific about:

  • Which config file (path and name)
  • Which fields to update
  • What the new values should be
  • What to do if field doesn't exist

2. Write Your Description

Update config/app.yaml:
- Change log_level from 'debug' to 'info'
- Change timeout from 30 to 60
- If these fields don't exist, add them under the 'application' section

3. Select Repositories

Start with repos you know have this config file. You can expand later.

4. Generate and Review

Check that Tidra:

  • Found the right file
  • Updated the right fields
  • Handled missing fields appropriately
  • Didn't change anything unexpected

Example: Update CI/CD Pipelines

Goal

Update all GitHub Actions workflows to use Node 20 instead of Node 16.

Description

Update all GitHub Actions workflow files (.github/workflows/*.yml):

Find this section:
- uses: actions/setup-node@v3
  with:
    node-version: '16'

Change to:
- uses: actions/setup-node@v4
  with:
    node-version: '20'

If the file uses actions/setup-node but doesn't specify a version, add node-version: '20'.

What to Check

Review that:

  • ✅ Node version changed to 20
  • ✅ Action version updated to v4
  • ✅ No other unintended changes
  • ✅ Syntax is still valid YAML

Common Issues

Multiple workflows per repo: Tidra will update all workflow files. Verify this is what you want.

Different action versions: If some repos use v2, some v3, mention this in your description.

Example: Standardize Docker Configurations

Goal

Update all Dockerfiles to use a specific base image.

Description

Update the Dockerfile in the root directory:

Change the FROM line to use our standard base image:
FROM node:20-alpine3.19

If the Dockerfile is currently using any node:* image, replace it with the above.
If using a different base (like ubuntu), leave it unchanged but add a comment:
# TODO: Migrate to node:20-alpine3.19 base image

What to Check

  • ✅ Base image updated correctly
  • ✅ Repos with non-Node images left alone
  • ✅ Comments added where appropriate
  • ✅ Multi-stage builds handled correctly

Example: Add Configuration Section

Goal

Add observability configuration to all services.

Description

Add an observability section to config/app.yaml:

Add this section:
observability:
  tracing:
    enabled: true
    endpoint: "https://tracing.company.com"
  metrics:
    enabled: true
    endpoint: "https://metrics.company.com"

Place it after the 'logging' section if present, otherwise at the end of the file.

If the file already has an 'observability' section, don't change it.

What to Check

  • ✅ New section added
  • ✅ Placement correct (after logging)
  • ✅ Proper YAML indentation
  • ✅ Existing observability sections untouched

Advanced: Conditional Updates

Goal

Update timeout values differently based on service type.

Description

Update config/app.yaml:

Update the 'timeout' field based on the service type:
- If the config includes 'service_type: api', set timeout: 60
- If the config includes 'service_type: worker', set timeout: 300
- If no service_type is specified, set timeout: 30

Place the timeout field under the 'application' section.

What to Check

  • ✅ Timeout values match service types
  • ✅ Defaults applied where no type specified
  • ✅ Field placed in correct section

Advanced: Config Format Migration

Goal

Migrate from JSON config to YAML.

Description

Convert config.json to config.yaml:

1. Read the existing config.json file
2. Convert the JSON structure to YAML format
3. Save as config.yaml in the same directory
4. Maintain all the same values and structure
5. Add a comment at the top: "# Migrated from config.json"

Do not delete config.json - we'll remove it in a follow-up initiative.

What to Check

  • ✅ All values preserved
  • ✅ Structure intact
  • ✅ Valid YAML syntax
  • ✅ Original JSON still present

Tips for Success

Be Explicit About File Paths

❌ "Update the config" ✅ "Update config/app.yaml in the root directory"

Show Current and Desired State

Include examples of what exists now and what it should become.

Handle Edge Cases

Mention what to do if:

  • File doesn't exist
  • Field is already set to target value
  • Multiple files match the pattern

Test with Diverse Repos

Pick test repos with:

  • Different config file structures
  • Some with and without the target fields
  • Different indentation/formatting styles

Common Mistakes

Assuming All Repos Are the Same

Different repos may have:

  • Different config file names
  • Different structures
  • Different field names

Account for this in your description.

Not Handling Missing Files

What if the config file doesn't exist? Should Tidra:

  • Create it?
  • Skip the repo?
  • Log a warning?

Be explicit.

Forgetting Formatting

YAML is sensitive to indentation. Mention expected formatting:

Add this section with 2-space indentation:
  observability:
    enabled: true

Next Steps

Updated 16 days ago