Group snapshots for mono-repos should only include components from one commit

[mh21]

Summary

In mono-repo applications, group snapshots currently combine builds from multiple MR commits when components have different "latest successful" builds. This is confusing for mono-repo workflows where users expect each MR version to be tested independently.

Affected Code

The group snapshot creation logic is in the integration-service repository:

• Repository: https://github.com/konflux-ci/integration-service
• Key files:
  • gitops/snapshot.go - GroupSnapshotInfoAnnotation, SetAnnotationAndLabelForGroupSnapshot, ComponentSnapshotInfo
  • internal/controller/snapshot/snapshot_adapter.go - controller logic for group snapshot creation

Current Behavior

Group snapshots use the latest successful build of each component across all MR versions, regardless of which commit they came from. This was most likely designed for multi-repo scenarios where:

• Different components live in different repos
• A logical change spans multiple repos (PR in repo-A + PR in repo-B)
• The pr-group-sha (computed from branch name) ties together related PRs across repos
• Combining builds from different commits is natural since repos have independent histories

Problem in Mono-Repos

In a mono-repo (like in the example below), all components are in the same repo. The current behavior causes confusing results.

Note: The Konflux documentation provides a workaround task for push events (post-merge) to check if all snapshot components have the same SHA before releasing. However, there is no workaround for the PR group testing behavior described here - this is the current design.

Example: rpms!231

Builds per commit:

SHA	Version	k8s1-35	catatonit	gpgme124	oras
f1759eae	v1	Succeeded	Succeeded	Succeeded	Failed
37a83ffd	v2	Succeeded	Failed	Failed
da7877cb	v3 (latest)		Succeeded	Succeeded

• v1: k8s1-35, catatonit, gpgme124 succeeded; oras failed → no group snapshot created
• v2: Only k8s1-35 succeeded, catatonit+gpgme124 failed (no oras changes) → no group snapshot possible
• v3: Only catatonit+gpgme124 built (no k8s1-35 changes), both succeeded

Resulting group snapshot rpms-main-h577d:

• kubernetes1-35-main from v2 (37a83ffd)
• catatonit-main from v3 (da7877cb)
• compat-gpgme124-main from v3 (da7877cb)

This is confusing because:

1. The group snapshot spans two commits that were never meant to be tested together
2. v3 only changed catatonit+gpgme124, but its group test includes k8s1-35 which wasn't touched in that commit
3. If v2's k8s1-35 build had a bug, it would cause v3's group test to fail despite v3 not changing k8s1-35

Proposed Solution

For mono-repo applications (single git repo with multiple components), group snapshots should:

1. Only include components that were built in the same commit
2. Not pull in "latest successful" builds from previous MR versions
3. If a component wasn't changed in a commit, it should NOT be included in that commit's group snapshot

Proposed behavior for v3:

In v3, only catatonit and gpgme124 were built (both succeeded). k8s1-35 was not changed in this commit.

	Current	Proposed
Group snapshot components	k8s1-35 (from v2) + catatonit + gpgme124	catatonit + gpgme124 only

The current behavior pulls in k8s1-35 from v2 because it's the "latest successful build" for that component across all MR versions. The proposed behavior would only include components that were actually built in v3.

This matches user expectations: "test what I changed in this commit"

Impact

This affects all mono-repo applications using Konflux group testing.

References

• Konflux monorepo documentation (workaround for push events only): https://konflux-ci.dev/docs/patterns/managing-monorepo-applications/
• Example MR: https://gitlab.com/redhat/hummingbird/rpms/-/merge_requests/231

[sonam1412]

STONEINTG-1481 should have addressed this issue. The changes are already in production.
@mh21 Could you please confirm if this issue is resolved for your team ?