sbom-create-commands does not work for custom builder

[peguin40]

Do you want to request a feature or report a bug? Report a bug

Please provide the following info:

• MBT Version: 1.2.45 -> current latest version
• OS Version: Github Actions
• If possible, provide a link to the project.

Steps to Reproduce:

1. Add sbom-create-commands to build-parameters
2. Observe pipeline run uses default bom creation commands instead of provided sbom-create-commands

According to https://github.com/SAP/cloud-mta-build-tool/blob/v1.2.45/internal/commands/commands.go#L363 , by including sbom-create-commands in builder build-parameters should use it instead of the provided bom creation commands. However it does not work

I have tried the following structures:

build-parameters:
      builder: custom
      build-result: gen
      commands:
        - npm run build
      sbom-create-commands: ["npx @cyclonedx/cyclonedx-npm --output-format XML --spec-version 1.4 --output-file bom-npm-sidecar.xml --omit dev"]

build-parameters:
      builder: custom
      build-result: gen
      commands:
        - npm run build
      sbom-create-commands:
        - npx @cyclonedx/cyclonedx-npm --output-format XML --spec-version 1.4 --output-file bom-npm-sidecar.xml --omit dev

[AliAltivate]

This looks like it has since been fixed on master, but is not in any released version yet — which would explain why it still reproduces for anyone on the latest release.

Root cause: when sbom-create-commands is written in mta.yaml, the YAML unmarshals into []interface{}, but GetModuleSBomGenCommands only did a direct type assertion to []string. That assertion failed for both of the YAML forms in the report (inline flow sequence and block sequence), customSbomGenCmds stayed empty, and the code fell through to the default SBOM commands — exactly the behaviour described.

Fixed by: #1212 (Fix sbom-create-commands type assertion to handle []interface{}) and #1245 (fix: correct sbom-create-commands []interface{} fallback and test compilation), both merged 2026-07-22. master now falls back to an []interface{} assertion and collects the string elements, and there are four specs covering it ([]string, []interface{} from YAML unmarshaling, the empty-list fallback, and skipping non-string elements) — all green locally on master (4 of 36 specs, 0 failed).

Why it probably still reproduces: the most recent release is v1.2.49 (2026-04-29), which predates both fixes. So anyone on a released mbt still has the old assertion.

@kbarnold — worth closing this once the next release goes out, or now with a note pointing at v1.2.50+? Happy to leave it to you; just flagging it so it isn't re-diagnosed from scratch.