enable mergequeue

[ThoFrank]

Merge queues could help us ensure, that we don't break the main branch.
It enables us to run checks right before a PR is merged. This way it will be detected if a PR needs to be rebased.

More info:
1 minute long intro Video
GH docs

[eclipse-otterdog]

This is your friendly self-service bot.

Thank you for raising a pull request to update the configuration of your GitHub organization.
You can manually add reviewers to this PR to eventually enable auto-merging.

The following conditions need to fulfilled for auto-merging to be available:

• valid configuration
• approved by a project lead
• does not require any secrets
• does not update settings only accessible via the GitHub Web UI
• does not remove any resource

Otterdog commands and options

You can trigger otterdog actions by commenting on this PR:

• /otterdog team-info checks the team / org membership for the PR author
• /otterdog validate validates the configuration change
• /otterdog validate info validates the configuration change, printing also validation infos
• /otterdog check-sync checks if the base ref is in sync with live settings
• /otterdog merge merges and applies the changes if the PR is eligible for auto-merging (only accessible for the author)
• /otterdog done notifies the self-service bot that a required manual apply operation has been performed (only accessible for members of the admin team)
• /otterdog apply re-apply a previously failed attempt (only accessible for members of the admin team)

[eclipse-otterdog]

This is your friendly self-service bot.

The author (ThoFrank) of this PR is associated with this organization in the role of NONE.

[eclipse-otterdog]

This is your friendly self-service bot.
Please find below the validation of the requested configuration changes:

Diff for db3c100

Organization automotive.openbsw[id=eclipse-openbsw]
  there have been 2 validation infos, enable verbose output with '-v' to to display them.

+  add repo_ruleset[name="main-mergequeue", repository="openbsw"] {
+    allows_creations                  = false
+    allows_deletions                  = false
+    allows_force_pushes               = false
+    allows_updates                    = true
+    bypass_actors                     = []
+    enforcement                       = "active"
+    exclude_refs                      = []
+    include_refs                      = [
+      "~DEFAULT_BRANCH"
+    ],
+    name                              = "main-mergequeue"
+    required_merge_queue              = {
+      build_concurrency                 = 5
+      max_group_size                    = 5
+      merge_method                      = "SQUASH"
+      min_group_size                    = 1
+      requires_all_group_entries_to_pass_required_checks = true
+      status_check_timeout              = 60
+      wait_time_for_minimum_group_size  = 5
+    }
+    required_pull_request             = {
+      dismisses_stale_reviews           = false
+      required_approving_review_count   = 2
+      requires_code_owner_review        = false
+      requires_last_push_approval       = false
+      requires_review_thread_resolution = false
+    }
+    required_status_checks            = {
+      do_not_enforce_on_create          = false
+      status_checks                     = [
+        "eclipse-eca-validation:eclipsefdn/eca"
+      ],
+      strict                            = false
+    }
+    requires_commit_signatures        = false
+    requires_deployments              = false
+    requires_linear_history           = false
+    target                            = "branch"
+  }
  
  Plan: 1 to add, 0 to change, 0 to delete.

[eclipse-otterdog]

This is your friendly self-service bot. The current configuration is in-sync with the live settings. 🚀

[netomi]

btw. a merge queue by itself will not protect you against breaking the target branch. You need to define some status checks that make sure the target branch is still in a good state after this changes have been applied, e.g. build the project and run tests.

Merge queue can help if you have lot of concurrent PRs that you wanna test in combination before merging them together. If you do that sequentially (as without a merge queue), it might take a while and this can be sped up with a merge queue.

the apoapsis project uses a merge queue: see https://github.com/eclipse-apoapsis/.eclipsefdn/blob/main/otterdog/eclipse-apoapsis.jsonnet#L102

[ThoFrank]

Thanks for the hint! Then I guess we'll need to add the merge_group trigger condition to our workflows first. I'll keep this PR in draft state until this is done.

[ThoFrank]

Hi again @netomi,
right now we have multiple jobs with the same name in different workflow files. Is this possible with otterdog?

[netomi]

so we just use what GitHub supports. If there are multiple jobs with the same id but no name, you will have to use the id. What then happens internally at GitHub I dont know for sure, as multiple jobs with the same id will add some checks to this commit. I would at least give them names so that you can distinguish them in the ruleset config.