How to recreate first-commit using commit_message_template / testing configs

[melink14]

Hi,

Background

With the advent of Github dependency review action and Dependabot metadata validation action, I feel safe enough to allow mergify to auto merge these PRs once checks pass.

As a bonus, I plan to disable Dependabot auto-rebase to allow mergify to attempt to update PRs only when they're at the head of the queue. (I will have Mergify send Dependabot recreate command on the conflict condition.)

For normal PRs, I use title+body template since I can enforce it matches convention and it can be easily changed to be canonical even as PR changes with review.

Dependabot PR bodies are special given they have a ton of extra metadata and don't match the commit message but they'll end up with extra merge commits when Mergify updates them so I can't use the default Github message since I beleive it appends all commit messages when there are more than one.

Questions

1. The squash action has a first-commit possibility (and no deprecation message) but the commit message documentation doesnt' mention how to emulate this using jinja templates. There's also no documentation about the shape of the commits attribute.

pull_request_rules:
  - name: Auto-merge dependabot
    conditions:
      # Also covered by Github protections but this reduces noise from mergify.
      - '#approved-reviews-by>=1'
      - author=dependabot[bot]
    actions:
      queue:
        name: default
        # Each PR is one commit, but may have extras added when mergify updates so squash
        method: squash
        commit_message_template: |
          {{ commits[0] }}

Since you access jinja lists with normal indexing, I tried just getting the first item in the commits list but that gave the following validation error:

Template syntax error for dictionary value @ pull_request_rules → item 0 → actions → queue → commit_message_template ``` list object has no element 0 ```

I also tried to use first filter, but got error that it wasn't a sequence. What should I do here?

2. How can I test a mergify config before running it on live code? It seems like the only way to see the final output of my commit message to commit it and wait for Dependabot. I was hoping the config validator would show the final commit message given an example PR but it only shows the value of various checks.

[melink14]

Had an ephiphany that I could avoid complicated solutions by setting dependabot's open-pull-requests-limit option to 1.

There will only ever be one open Dependabot PR which means I can allow dependabot to update itself without worrying about excess CI runs due to parallel Dependabot PRs. The overhead of only having 1 at a time is minimal due to auto merging especially if it happens in the middle of the night.

It'd still be good to get the questions above answered (since a busy repo would still want to a complete solution) but for now I think I can just go with a non queue based solution as proposed in a prior discussion:

pull_request_rules:
  - name: Auto-merge dependabot
    conditions:
      # Also covered by Github protections but this reduces noise from mergify.
      - '#approved-reviews-by>=1'
      - author=dependabot[bot]
      - '#commits-behind=0'
      # Don't auto-merge PRs where non dep change had to be commited as well
      - '#commits=1'
    actions:
      merge:
        method: squash

[melink14]

After trying this out on my repo had to make a few more tweaks after running to an issue where Dependabot creates already stale PRs in response to newly available PR quota that comes from merging the current dependabot PR: dependabot/dependabot-core#4031

In this state, Dependabot will wait forever without updating so my rule above does nothing. I was a bit worried about how to create a non greedy rule to cause Dependabot to rebase itself but in the end I went with the simplest rule I could think of and it seems to work alright.

  - name: Have Dependabot rebase when out of date
    # Sometimes Dependabot creates a PR on an old branch and never updates.
    # See dependabot/dependabot-core#4031
    conditions:
      # Also covered by Github protections but this reduces noise from mergify.
      - '#approved-reviews-by>=1'
      - author=dependabot[bot]
      - '#commits-behind>0'
      # Don't auto-merge PRs where non dep change had to be committed as well
      - '#commits=1'
    actions:
      comment:
        message: '@dependabot rebase'

I was worried that since the conditions would be valid continuously it would cause more than one comment to be made until rebase was finished but is seems that Mergify handles that pretty well (it makes sense based on the conflict examples in the docs).

[jd]

Hi @melink14

To answer your questions:

1. The commits attribute contains the sha1 of commits, so it's not useful here. It's mostly exposed for using with #commits and that's it. The goals would be to expose all attributes from all commits in the future so you could use those in a template.

2. For commit messages, we don't have a good story indeed.

I'll add both items on our roadmap.

[melink14]

Thanks alot for the answer and adding it to the road map!

For now, the workaround above should work fine for me and I'll look forward to all the improvements coming into Mergify.