Autobump and new dependencies

[lelegard]

Hi,

What would be the preferred / recommended workflow when a formula is managed by autobump and some new version requires additional modifications in the formula, typically new dependencies?

I just got a similar issue. It was solved but maybe not in the best way. I am the maintainer of the TSDuck project (formula tsduck). This project was added to the autobump list a few versions ago by HomeBrew maintainers, which is great. Yesterday evening, I published a new release on GitHub, where the source code of the project is managed. During the night, the autobump job detected the new release and created the corresponding PR in homebrew-core. However, because the documentation of the project was just migrated to asciidoc format, a new dependency was required. Since autobump cannot guess that, it only updated the version and, of course, the build failed in the PR.

When I didn't see the new version in the morning, I searched for an autobump PR for tsduck and discovered the error. I created another PR from scratch with the new version and new dependencies, with proper comment. A HomeBrew maintainer (thanks @carlocab) accepted my new PR and closed the autobump PR.

So far, so good. But is it the best workflow? Is there a recommended method to anticipate the modifications in a formula (other than the version) before autobump runs?

If we fix the formula content before releasing the new version N of the project, it will probably create a useless intermediate form of version N-1 with useless dependencies (which are needed starting with version N only).

If we wait for autobump to fail, as it happened in my case, and provide another PR, we create additional burden on HomeBrew maintainers and wasted processing time in the CI because of the failed runs.

Any other idea or guidelines?

[SMillerDev]

If we wait for autobump to fail, as it happened in my case, and provide another PR, we create additional burden on HomeBrew maintainers and wasted processing time in the CI because of the failed runs.

You could also make a comment in the autobump PR but generally I think this creates the least burden on maintainers since it just fixes a build.

[iMichka]

Thanks for the feedback.

Autobump opens more than 50 pull requests / day, and it makes us gain a lot of time as maintainers.
Having a few of these builds failing is sort of expected. A missing dependency is one of the things that can happen, but there are a lot of other reasons a new version might break. We will review the failed ones and fix them.

Of course we are happy when upstream maintainers come and see the broken build, and help get things sorted out quickly: this avoids us having to dig through changelogs or open upsream issues if we can't understand what is going on.

So don't worry: if we are not able to fix a broken build we will let you know through a ticket. It delays the release of the new version, but that might have happened anyway if a human opened the pull request manually instead.