[TECHNICAL] SBOM changes to be pushed in an specific branch with signed commits

[jesmrec]

New logic of the workflow:

• After merging a PR into master, the workflow is triggered
• cycloneDx generates an SBOM over the new HEAD of master
• Fetch the existing sbom file in the chore/sbom-update branch, if the branch exists. If not, get the origin/master one. The idea is getting the newest version to compare with
• Both sbom files (the one generated in the workflow and the existing one to compare) are normalized and sorted to be compared using jq, in order to know if there are changes or not.
  • If there are changes -> create/update chore/sbom-update
  • If there are no changes -> stop

---

• Added a manual dispatch in case dependencies are updated inside of a release branch, with target branch as parameter and master as default
• Removed concurrency policy. Every PR must trigger the workflow to check dependencies.
• Added an step to the release template to merge the sbom branch before creating release branch

Related Issues

App:

• Add changelog files for the fixed issues in folder changelog/unreleased. More info here
• Add feature to Release Notes in ReleaseNotesViewModel.kt creating a new ReleaseNote() with String resources (if required)

---

QA

[jesmrec]

Moving to "In progress" again to inspect an issue before reviewing @joragua @DeepDiver1975

[jesmrec]

Ready for review again!

[joragua]

Somme comments here @jesmrec!

[DeepDiver1975]

PR Review: SBOM Workflow — Signed Commits to Dedicated Branch

Overview

This PR restructures the SBOM generation CI workflow to address security policy requirements. Key changes:

• Workflow now triggers only on master pushes (previously: all feature/fix/etc. branches)
• Replaced direct commit push with peter-evans/create-pull-request to maintain a chore/sbom-update branch
• Added sign-commits: true for verified commits
• Improved output variable naming (changes=true/false vs inverted no_changes)
• Added manual dispatch with configurable target_branch
• Added release template step to merge the SBOM branch before cutting a release

---

Code Quality & Style

Improvements:

• Cleaner boolean semantics: changes=true/false is much more readable than the old no_changes=true/false
• Conditional token generation (if: steps.compare.outputs.changes == 'true') avoids unnecessary API calls — good practice
• All action pins use commit SHAs — secure
• Comparison logic is well-documented with inline comments

Issues:

1. Missing error fallback in git show — This is a regression. The old code had || echo '{}' > sbom_prev.json; the new code does not:

   git show "$PREVIOUS_SBOM_REF:sbom.json" > sbom_prev.json

   If sbom.json doesn't exist on origin/master (e.g., first run, or on a freshly dispatched non-master target_branch), the workflow will fail hard instead of gracefully treating it as an empty/new SBOM.

2. fetch-depth: 2 is now vestigial — This was needed for the old HEAD~1 comparison. Now that comparison is done against remote branches, depth 2 provides no benefit. Minor cleanup opportunity.

3. Hardcoded FALLBACK_BRANCH="master" — When dispatching manually with a custom target_branch, the fallback for comparison is still master, not the target branch. This may be intentional (always compare against master as the source of truth), but deserves a comment explaining the reasoning.

---

Logic & Correctness

4. No concurrency policy + push to master — The PR description says "Removed concurrency policy. Every PR must trigger the workflow." But with the trigger now being push: branches: [master], rapid consecutive merges to master could create race conditions where two workflow runs both try to create/update chore/sbom-update. The peter-evans/create-pull-request action handles the "update existing PR" case, but concurrent git operations on the same branch without a concurrency guard can still cause conflicts. Consider re-adding a concurrency group scoped to the source branch:

   concurrency:
     group: sbom-update
     cancel-in-progress: false

5. Infinite loop potential — low risk but worth documenting — When chore/sbom-update is merged into master, the workflow triggers again. Because delete-branch: true removes the branch on merge, the fallback to origin/master will be used, and the generated SBOM should match master's SBOM exactly → changes=false → workflow stops cleanly. This is correct behavior, but it's non-obvious and worth a brief comment in the workflow.

---

Security

6. sign-commits: true requires App configuration — This is the core security improvement, but sign-commits: true in peter-evans/create-pull-request requires the GitHub App to have commit signing configured at the organization level. If SBOM_APP_ID/SBOM_APP_PRIVATE_KEY don't have the required permissions, this will fail silently or with a cryptic error. Confirm the App has been granted signing capabilities.

7. permissions: contents: write — Broad but carried over from the previous version; no regression.

---

Minor

8. Typo in changelog entry (changelog/unreleased/4837):

   "pushing them to an specific branch"

   Should be "a specific branch."

---

Summary

Area	Status
Core logic	Correct
Security improvement	Solid — signed commits via App token is the right approach
Regression risk	git show lacks the old || echo '{}' fallback
Race condition	Possible without concurrency guard
Cleanup	fetch-depth: 2 vestigial

The overall approach is sound and the goal (signed, auditable SBOM commits) is well-implemented. The main items to address before merging are the missing git show error fallback and clarifying the concurrency strategy.

[jesmrec]

Issues

1. Missing error fallback in git show — This is a regression. The old code had || echo '{}' > sbom_prev.json; the new code does not:
   git show "$PREVIOUS_SBOM_REF:sbom.json" > sbom_prev.json
   If sbom.json doesn't exist on origin/master (e.g., first run, or on a freshly dispatched non-master target_branch), the workflow will fail hard instead of gracefully treating it as an empty/new SBOM.

I think it can be safety assumed that origin/master will always contain an sbom.json file.

2. fetch-depth: 2 is now vestigial — This was needed for the old HEAD~1 comparison. Now that comparison is done against remote branches, depth 2 provides no benefit. Minor cleanup opportunity.

right, removed.

3.Hardcoded FALLBACK_BRANCH="master" — When dispatching manually with a custom target_branch, the fallback for comparison is still master, not the target branch. This may be intentional (always compare against master as the source of truth), but deserves a comment explaining the reasoning.

comment added

4.No concurrency policy + push to master — The PR description says "Removed concurrency policy. Every PR must trigger the workflow." But with the trigger now being push: branches: [master], rapid consecutive merges to master could create race conditions where two workflow runs both try to create/update chore/sbom-update. The peter-evans/create-pull-request action handles the "update existing PR" case, but concurrent git operations on the same branch without a concurrency guard can still cause conflicts. Consider re-adding a concurrency group scoped to the source branch:

concurrency added again to create a queue in case more than one execution tries to write in the branch at the time.

5. Infinite loop potential — low risk but worth documenting — When chore/sbom-update is merged into master, the workflow triggers again. Because delete-branch: true removes the branch on merge, the fallback to origin/master will be used, and the generated SBOM should match master's SBOM exactly → changes=false → workflow stops cleanly. This is correct behavior, but it's non-obvious and worth a brief comment in the workflow.

SBOM updates will never change SBOM content. no action required, IMO

6. sign-commits: true requires App configuration — This is the core security improvement, but sign-commits: true in peter-evans/create-pull-request requires the GitHub App to have commit signing configured at the organization level. If SBOM_APP_ID/SBOM_APP_PRIVATE_KEY don't have the required permissions, this will fail silently or with a cryptic error. Confirm the App has been granted signing capabilities.

permissions are granted from the proper github app. Nothing to do here.

7. permissions: contents: write — Broad but carried over from the previous version; no regression.

👍

8. Typo in changelog entry (changelog/unreleased/4837):

Fixed

@DeepDiver1975

[joragua]

Good job @jesmrec! 🚀