ROX-34007: Enhance auto-merge configurability by tommartensen · Pull Request #91 · stackrox/actions

tommartensen · 2026-04-10T12:25:45Z

This is done in preparation for auto-merging MintMaker/Renovate updates in stackrox/stackrox, while keeping control over the required checks outside of GH branch protection rules.

Validation

Local

test/local-env.sh automerge/automerge.sh <repository> <limit> <label1,label2,...> <allowed-author> <required-checks> <allowed-base-branches>

Default configuration

test/local-env.sh automerge/automerge.sh stackrox/stackrox 50 auto-merge app/dependabot '.*' '.*'

Intended use for MintMaker

test/local-env.sh automerge/automerge.sh stackrox/stackrox 50 'konflux-build' 'app/red-hat-konflux' '^(?!.*conforma)Red Hat Konflux' 'master'

(I want to update the Renovate config such that it sets mintmaker and auto-merge label on each update, but we're not there yet, hence testing with konflux-build)

GHA

kurlov

Looks good

kurlov · 2026-04-13T11:57:06Z

+        and (.name | test("'"${REQUIRED_CHECKS}"'"))
+        ))
+    | {
+        ALL_SUCCESS: (length > 0 and all(.conclusion == "SUCCESS" or .conclusion == "SKIPPED"))


Two corner cases:

What if REQUIRED_CHECKS doesn't match to any actual checks? Then auto-merge will not happen even if all checks SUCCESS

Do we really want to auto-merge a PR which has all REQUIRED_CHECKS checks SKIPPED?

I think that is expected behavior. I will add a comment to the function. For example, if Konflux builds are required, but not triggered by the PR, they will not show up in the list.

Previously, we relied on status roll up, which returns GREEN if all checks have succeeded or been skipped. I want to keep it like this (also for backwards compatibility). But your question brought up a bug in my implementation, I forgot about the StatusChecks (OSCI).

msugakov

I skipped checking get_combined_success_status this time because it scares me.
Will do it in the next go.

msugakov · 2026-04-13T17:31:34Z


 inputs:
+  allowed-authors:
+    description: 'Authors to filter PRs for auto-merge (comma-separated)'


Nit: "Authors to filter PRs for auto-merge (comma-separated)" is confusing. How about "Authors (comma-separated) whose PRs will be auto-merged".

Also, please mention what happens when its value is empty. See related #91 (comment)

Done in 430f1c2 as suggested.

The description after the update says Authors (comma-separated) to filter PRs for auto-merge.
I still find this problematic because "to filter" could mean either "to keep" or "to remove" (i.e. "filter out").

msugakov · 2026-04-13T17:34:21Z

-  label:
-    description: 'Label to filter PRs for auto-merge'
+  labels:
+    description: 'Labels to filter PRs for auto-merge (comma-separated `and` logic)'


I'd suggest something like "Only PRs having these labels will be merged. Multiple labels can be specified as comma-separated, each of them must be present on the PR."

Also, please mention what happens when an empty value is specified. See related #91 (comment)

Done, please check the empty value clause.

msugakov · 2026-04-13T17:38:18Z

+    check_not_empty \
+        DRY_RUN GH_TOKEN \
+        REPOSITORY LIMIT LABELS ALLOWED_AUTHORS REQUIRED_CHECKS ALLOWED_BASE_BRANCHES


Hm. Since you have check_not_empty on all CLI arguments here, should required: false be changed to required: true in GitHub inputs definitions?

The inputs are not required on the action level (mostly for backwards compatibility) and we provide reasonable defaults there.
In the script however, each of these inputs needs to be defined. If a workflow calling the action does not provide an input, the default from the action's inputs section will be used.

Alternatively, we could provide defaults again in the script (duplicate the defaults from the action definition) or work with named arguments (overhead).

TLDR: For backwards compatibility and simplicity, we should keep the current implementation.

How does the combination of

default: 'blah' required: false

work?

If the caller does not provide the attribute, the default blah value gets passed in, right? That's the point of defaults.

required: false may only play a role when the attribute is specified but a null/empty value is passed. I.e. the caller would explicitly do

steps: - uses: my-fancy-action with: blah: null

Is this a backward compatibility scenario to be at all concerned about?

msugakov · 2026-04-13T18:10:40Z

+            echo "[DEBUG] PR #${PR_NUMBER} skipped - base branch '${BASE_BRANCH}' not allowed"
+            continue


The default limit=50 does not seem particularly high. It may happen that at some point we would have >50 PRs that pass basic criteria (matching repo, labels, be open and mergeable, not be draft) but that are open against different branches.
The script will start, load 50 PRs and then filter them out. I mean not just this spot but also filtering by status.

Is there any way to randomize the results of gh pr list ... command so that there's at least a chance to get things going in case there are >50 non-eligible PRs?

Alternatively, gh pr list ... can load many more results, potentially all. We should not have more than a couple thousands open PRs (famous last words) total, much less will pass basic criteria.
The we reshuffle those results and process up to limit in one run.

Counterpoint: Why may it be okay to have the current limit?

Generally: Because we go through the list of PRs relatively quickly, so it shouldn't grow too much

Dependabot: We don't observe issues with this number, it was fine before, so I assume it will be in the future.

MintMaker: Because we go through the list of PRs relatively quickly, so it shouldn't grow too much. 50 may be a good compromise: (3 + 1) branches * 4 types of updates = 16 MintMaker PRs concurrently. Even if we keep release branches for EUS support, we could support 12 branches in parallel.

I think 50 is a good compromise for now, and I would not invest in optimizations with randomization or custom limit implementations. If we encounter >50 PRs, we can revisit this.

The MintMaker assumption may not hold infinitely true. MintMaker will keep opening PRs against the release branches after we do the last release before EoL but before we tear down the setup.
We don't have a garbage collector or a step to go and close stale MintMaker PRs when sunsetting a version stream.

My main concern at this point is how would we find out when we encounter >50 PRs given that this action is to be executed in cron workflow which does not report its status on a PR?

The same question applies to #91 (comment): how would the engineer find out that gh pr review ... --approve ... command failed?

msugakov · 2026-04-13T18:15:55Z

+                gh pr review --repo "${REPOSITORY}" \
+                    --approve "${PR_NUMBER}"


I spotted the older command had || true at the end. Do you know why that was done?

I assume it was done to continue the workflow if approval fails. I would actually prefer to let it fail (not silently), because only if it breaks, engineers will investigate and implement improvements if necessary.

Enhance auto-merge configurability

e8e310b

tommartensen self-assigned this Apr 10, 2026

tommartensen added 7 commits April 10, 2026 14:27

ignore shellcheck warning for GH API GraphQL query

8036b7d

test dry-run input

db189d3

fix path to common.sh

92ef0f2

less verbose output

d19bfca

undo dry-run guard, fix input parameters

3b1b681

fix: use gh_log debug instead of gh_summary

63ad0ed

improvement to output

9c70984

tommartensen mentioned this pull request Apr 10, 2026

ROX-34007: Auto-merge MintMaker updates stackrox/stackrox#19944

Open

10 tasks

self-review

59de5bb

tommartensen requested a review from msugakov April 10, 2026 13:29

tommartensen marked this pull request as ready for review April 10, 2026 13:29

tommartensen requested a review from a team as a code owner April 10, 2026 13:29

tommartensen requested a review from kurlov April 10, 2026 13:29

kurlov reviewed Apr 13, 2026

View reviewed changes

tommartensen added 2 commits April 13, 2026 16:47

address review comments; add StatusChecks for testing

c3f2894

fix shellcheck

e320206

tommartensen requested a review from kurlov April 13, 2026 15:41

msugakov reviewed Apr 13, 2026

View reviewed changes

kurlov approved these changes Apr 13, 2026

View reviewed changes

tommartensen added 2 commits April 14, 2026 13:33

simple code review suggestions

430f1c2

use simplification for allowed_authors

831e3d0

tommartensen requested a review from msugakov April 14, 2026 11:48

		echo "[DEBUG] PR #${PR_NUMBER} skipped - base branch '${BASE_BRANCH}' not allowed"
		continue

		gh pr review --repo "${REPOSITORY}" \
		--approve "${PR_NUMBER}"

Conversation

tommartensen commented Apr 10, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Validation

Local

Default configuration

Intended use for MintMaker

GHA

Uh oh!

kurlov left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

tommartensen Apr 13, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

msugakov left a comment

Choose a reason for hiding this comment

Uh oh!

msugakov Apr 13, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

msugakov Apr 13, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

tommartensen commented Apr 10, 2026 •

edited

Loading

tommartensen Apr 13, 2026 •

edited

Loading

msugakov Apr 13, 2026 •

edited

Loading

msugakov Apr 13, 2026 •

edited

Loading