Skip to content

Conversation

jwbron
Copy link
Contributor

@jwbron jwbron commented Aug 21, 2025

Summary:

Added comprehensive resource tagging support to the scheduled-job Terraform module with automatic tags and custom tag support.

Changes Made

scheduled-job Module

  • Added tags variable to allow custom tagging
  • Added automatic tagging using existing module variables
  • Applied labels to all supported resources
  • Updated README with tagging documentation
  • Updated example configurations to demonstrate tagging

Module-Specific Tags

scheduled-job Module:

  • module = "scheduled-job"
  • job_name = var.job_name
  • execution_type = var.execution_type

Other Modules

  • github-ci-bootstrap: No tagging support (resources don't support labels)
  • cloud-build-docker: No tagging support (only data source, no resources)

Resource Support

Resource Type scheduled-job github-ci-bootstrap cloud-build-docker
Storage Buckets ✅ Labels N/A N/A
Storage Objects ✅ Metadata N/A N/A
PubSub Topics ✅ Labels N/A N/A
Cloud Functions ✅ Labels N/A N/A
Cloud Run Jobs ✅ Labels N/A N/A
Service Accounts ⚠️ Limited ⚠️ Limited N/A
Workload Identity N/A ⚠️ Limited N/A
Container Images N/A N/A ⚠️ Limited

Legend:

  • Full Support: Labels/tags applied automatically
  • ⚠️ Limited Support: Some resources may not support labels in Google provider
  • N/A Not Applicable: Resource type not used in this module

Example Usage

module "my_function" {
  source = "git::https://github.com/Khan/terraform-modules.git//terraform/modules/scheduled-job?ref=v1.0.0"
  
  job_name = "my-function"
  # ... other configuration
  
  tags = {
    environment = "production"
    team        = "data-engineering"
    owner       = "data-team"
  }
}

Benefits

  • Resource Organization: Easy identification and grouping of resources
  • Cost Management: Track costs by team, project, or environment
  • Compliance: Support for governance requirements
  • Automation: Enable automated resource management and cleanup
  • Auditing: Better visibility into resource ownership and purpose

Backward Compatibility

  • All changes are backward compatible
  • tags variable defaults to empty map {}
  • Existing configurations continue to work without modification
  • Automatic tags are always applied; custom tags are optional

Additional Improvements

  • Made job_image variable optional with proper validation for Cloud Run Jobs
  • Fixed linter issues by removing unused variables and locals from modules that don't support tagging

Issue: INFRA-XXXX

Test plan:

Update culture-cron to use these updated modules, verify tags were created.

@jwbron jwbron self-assigned this Aug 21, 2025
@jwbron jwbron force-pushed the resource-tagging branch 2 times, most recently from 7d20313 to b51d236 Compare August 21, 2025 17:51
@jwbron jwbron changed the title Add tags or labels to all resource created with shared modules Add tags or labels to all resources created with shared modules Aug 21, 2025
@jwbron jwbron force-pushed the resource-tagging branch 3 times, most recently from a5ebf9a to e83dc71 Compare August 21, 2025 18:20
@jwbron jwbron marked this pull request as ready for review August 21, 2025 18:31
@jwbron jwbron requested a review from a team August 21, 2025 18:32
Copy link
Member

@csilvers csilvers left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good idea!

- `main_file` - Python file name (e.g., "main.py"), relative to `source_dir`.
- `schedule` - Cron expression (e.g., "0 9 * * 1-5")
- `description` - Function/job description
- `owner` - The owner/team responsible for this scheduled job
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice! Do we want to use some consistent way of naming the team? Like should it be a github tag (@owner or #team), or the list of teams in ownership_data.json, or something else?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I should probably add a predefined list of teams here.


# Common tags for all resources
locals {
common_tags = merge(var.tags, {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seems misnamed -- I'd expect common_tags to just be the 3 common tags you list below, not that merged with var.tags. Should it be all_tags maybe?

Also, who wins in case of a merge conflict? I'm guessing that the ones below take precedence over the ones in var.tags. Is that the desired behavior?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this means "common for all resources generated by this usage of this module". Does "all_tags" sound better to you?

Good call on the merge conflicts, I'll make sure your guess is correct and document it.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

all_tags sounds good to me!

```

### Supported Resources
The following resources support tagging/labeling:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What happens if you try to add tags somewhere else? It seems like it's just silently ignored?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you add a field not supported in a terraform resource (in this case label or tag), it fails well before an apply, I think it's during the check stage.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants