feat: add data migration skip options to migrateDatabase job

[ctron]

Summary

• Add dataMigrationSkip (list of migration names) and dataMigrationSkipAll (boolean) values to the migrateDatabase module
• These set the MIGRATION_DATA_SKIP and MIGRATION_DATA_SKIP_ALL environment variables on the migration job
• Useful when data migrations have been run separately (e.g. via the concurrent data migration procedure from docs: add concurrent data migration procedure guide trustify#2421)

Example usage

modules:
  migrateDatabase:
    enabled: true
    dataMigrationSkip:
      - m0002000_add_sbom_properties
      - m0002010_add_advisory_scores

or to skip all data migrations:

modules:
  migrateDatabase:
    enabled: true
    dataMigrationSkipAll: true

Test plan

• helm template with dataMigrationSkip list renders MIGRATION_DATA_SKIP with comma-separated values
• helm template with dataMigrationSkipAll: true renders MIGRATION_DATA_SKIP_ALL=true
• helm template without either option renders no MIGRATION_DATA_* env vars

🤖 Generated with Claude Code

Summary by Sourcery

Add configuration options to control skipping data migrations in the migrateDatabase Helm module.

New Features:

• Introduce dataMigrationSkip and dataMigrationSkipAll options for the migrateDatabase module to selectively skip data migrations.

Enhancements:

• Expose MIGRATION_DATA_SKIP and MIGRATION_DATA_SKIP_ALL environment variables in the migrate-database job based on module configuration.
• Document example usage of dataMigrationSkip and dataMigrationSkipAll in values.yaml for Helm users.

[sourcery-ai]

Reviewer's Guide

This PR adds configuration options to the migrateDatabase Helm module to skip specific or all data migrations by wiring new values through the chart schema, default values, and the migration Job’s environment variables.

Flow diagram for migrateDatabase data migration skip configuration

flowchart LR
  values_yaml["values.yaml modules.migrateDatabase"] --> schema["values.schema.yaml migrateDatabase module schema"]
  schema --> tmpl["020-Job.yaml Helm template"]

  values_yaml -->|dataMigrationSkip list| env_skip["MIGRATION_DATA_SKIP env var"]
  values_yaml -->|dataMigrationSkipAll true| env_skip_all["MIGRATION_DATA_SKIP_ALL env var"]

  tmpl --> env_skip
  tmpl --> env_skip_all

Loading

File-Level Changes

Change	Details	Files
Add new migrateDatabase module options for skipping data migrations and validate them in the values schema.	Extend the migrateDatabase module schema to support a dataMigrationSkip string array value. Extend the migrateDatabase module schema to support a dataMigrationSkipAll boolean value with default false. Document that dataMigrationSkipAll conflicts with dataMigrationSkip and describe how each option maps to migration job env vars.	charts/trustify/values.schema.yaml
Wire the new skip options into the migrateDatabase Job template as environment variables.	Render MIGRATION_DATA_SKIP env var when dataMigrationSkip is set, joining the list with commas and quoting the value. Render MIGRATION_DATA_SKIP_ALL env var as "true" when dataMigrationSkipAll is enabled. Ensure that when neither option is set, no MIGRATION_DATA_* env vars are rendered.	charts/trustify/templates/init/migrate-database/020-Job.yaml
Expose the new skip options in the default values file with commented examples.	Add commented dataMigrationSkip example showing migration names to skip. Add commented dataMigrationSkipAll default value to indicate how to skip all data migrations.	charts/trustify/values.yaml

---

Tips and commands

Interacting with Sourcery

• Trigger a new review: Comment @sourcery-ai review on the pull request.
• Continue discussions: Reply directly to Sourcery's review comments.
• Generate a GitHub issue from a review comment: Ask Sourcery to create an
  issue from a review comment by replying to it. You can also reply to a
  review comment with @sourcery-ai issue to create an issue from it.
• Generate a pull request title: Write @sourcery-ai anywhere in the pull
  request title to generate a title at any time. You can also comment
  @sourcery-ai title on the pull request to (re-)generate the title at any time.
• Generate a pull request summary: Write @sourcery-ai summary anywhere in
  the pull request body to generate a PR summary at any time exactly where you
  want it. You can also comment @sourcery-ai summary on the pull request to
  (re-)generate the summary at any time.
• Generate reviewer's guide: Comment @sourcery-ai guide on the pull
  request to (re-)generate the reviewer's guide at any time.
• Resolve all Sourcery comments: Comment @sourcery-ai resolve on the
  pull request to resolve all Sourcery comments. Useful if you've already
  addressed all the comments and don't want to see them anymore.
• Dismiss all Sourcery reviews: Comment @sourcery-ai dismiss on the pull
  request to dismiss all existing Sourcery reviews. Especially useful if you
  want to start fresh with a new review - don't forget to comment
  @sourcery-ai review to trigger a new review!

Customizing Your Experience

Access your dashboard to:

• Enable or disable review features such as the Sourcery-generated pull request
  summary, the reviewer's guide, and others.
• Change the review language.
• Add, remove or edit custom review instructions.
• Adjust other review settings.

Getting Help

• Contact our support team for questions or feedback.
• Visit our documentation for detailed guides and information.
• Keep in touch with the Sourcery team by following us on X/Twitter, LinkedIn or GitHub.

[sourcery-ai]

Hey - I've found 2 issues, and left some high level feedback:

• The values.schema.yaml description says dataMigrationSkipAll conflicts with dataMigrationSkip, but this isn’t enforced; consider adding explicit schema validation or Helm template logic to fail or ignore one when both are set.

Prompt for AI Agents

Please address the comments from this code review:

## Overall Comments
- The values.schema.yaml description says dataMigrationSkipAll conflicts with dataMigrationSkip, but this isn’t enforced; consider adding explicit schema validation or Helm template logic to fail or ignore one when both are set.

## Individual Comments

### Comment 1
<location path="charts/trustify/values.schema.yaml" line_range="274-283" />
<code_context>
           - $ref: "#/definitions/Feature"
           - $ref: "#/definitions/Image"
           - $ref: "#/definitions/Application"
+          - type: object
+            properties:
+              dataMigrationSkip:
+                type: array
+                items:
+                  type: string
+                description: |
+                  List of data migration names to skip during the migration job.
+                  Sets the `MIGRATION_DATA_SKIP` environment variable.
+              dataMigrationSkipAll:
+                type: boolean
+                default: false
+                description: |
+                  Skip all data migrations. Sets the `MIGRATION_DATA_SKIP_ALL` environment variable.
+                  Conflicts with `dataMigrationSkip`.

       createImporters:
</code_context>
<issue_to_address>
**issue (bug_risk):** New migrateDatabase object in the `oneOf` may conflict with existing usages of Feature/Image/Application.

Adding a plain `type: object` branch with `dataMigrationSkip` / `dataMigrationSkipAll` makes the `oneOf` describe four mutually exclusive shapes. Because `values.yaml` uses both `image: {}` and these migration fields, a strict JSON Schema validator would reject it for matching multiple `oneOf` branches. If these fields are meant to extend Application (or another existing definition), consider using `allOf` to compose them in, or add them directly to that definition instead of via `oneOf`.
</issue_to_address>

### Comment 2
<location path="charts/trustify/templates/init/migrate-database/020-Job.yaml" line_range="49-52" />
<code_context>
             {{- include "trustification.postgres.envVars" ( dict "root" . "database" ( merge ( required "Using migrateDatabase requires setting .Values.migrateDatabase" (deepCopy .Values.migrateDatabase) ) ( deepCopy .Values.database ) ) ) | nindent 12 }}
             {{- include "trustification.storage.envVars" $mod | nindent 12 }}

+            {{- with .Values.modules.migrateDatabase.dataMigrationSkip }}
+            - name: MIGRATION_DATA_SKIP
+              value: {{ join "," . | quote }}
+            {{- end }}
+            {{- if .Values.modules.migrateDatabase.dataMigrationSkipAll }}
+            - name: MIGRATION_DATA_SKIP_ALL
</code_context>
<issue_to_address>
**suggestion (bug_risk):** `dataMigrationSkip` and `dataMigrationSkipAll` can be set simultaneously despite being described as conflicting.

The chart currently permits both values, causing both `MIGRATION_DATA_SKIP` and `MIGRATION_DATA_SKIP_ALL` to be set, which contradicts their documented conflict and may yield ambiguous behavior in the migration job. Please either enforce mutual exclusivity in the template (e.g., fail when both are set) or define and rely on a clear precedence rule when both are present.
</issue_to_address>

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

_{Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.}

[sourcery-ai]

issue (bug_risk): New migrateDatabase object in the oneOf may conflict with existing usages of Feature/Image/Application.

Adding a plain type: object branch with dataMigrationSkip / dataMigrationSkipAll makes the oneOf describe four mutually exclusive shapes. Because values.yaml uses both image: {} and these migration fields, a strict JSON Schema validator would reject it for matching multiple oneOf branches. If these fields are meant to extend Application (or another existing definition), consider using allOf to compose them in, or add them directly to that definition instead of via oneOf.