Single push

[nbauma109]

Is it possible to do only one push for all commits ? Because for now it's one push per commit and each push triggers a build on CI infrastructure.

[martingjaldbaek]

Hey, I'm not sure I follow - could you elaborate? Dependabot creates one branch and PR per dependency update - that's out of my control (and the whole reason I created this workflow in the first place). This workflow then creates a new branch into which it merges each of those branches (or as many as possible without merge conflicts). Technically it doesn't even push this combined branch, because it creates it directly in GitHub via the GitHub API (rather than creating it locally and pushing the changes afterward). And then finally it opens a PR for this branch (which then tends to trigger CI). So there's only ever one "push" by this workflow.

If you want to avoid the many PRs (and subsequent CI runs) that dependabot creates to begin with, then like the README says, there's currently no other option than using a different tool that offers this option, such as Depfu or Renovate.

[nbauma109]

Each dependabot PR triggers a build and it's fine. The combined PR has as many merge commits in addition to the bump commits and each of these merge commit trigger a build.

[nbauma109]

Example here https://github.com/nbauma109/jd-core/pull/28

[nbauma109]

Screenshot of jitci

[martingjaldbaek]

Ah, thank you for elaborating. I'll investigate if there's a way to prevent this without loss of functionality. I have a feeling it's only possible by using a local shell checkout, that doesn't push until the end. However that entails splitting the workflow up into multiple actions again (in order to add the shell github action in between the js github actions that fetch the PRs in the beginning, and create the PR for the combined branch at the end). I'm not convinced this is worth the tradeoff for a general release, with the added complexity of multiple steps, and added security risk (e.g. injection attacks) that a general shell comes with - it used to be split up like that, but I changed it to a single js action for the 1.3.0 release.

For the moment, if you want, you can revert to the 1.2.0 release instead - it used a single "octopus merge" commit to merge all the branches in one go. However it also comes with the downside that if any of the branches cause a merge conflict, all the merges fail, in which case you'll have to use the "nocombine" label on the PR to exclude the troublemaker branch(es) and try again. If you're interested in trying to recreate the automatic merge conflict handling from the 1.3.0 release using a git shell action instead, this is where I'd fork from.

As a workaround, I know some CI providers (I use CircleCI) provide an option to have a build cancel if a newer commit is pushed on the same branch. I have Circle set up that way, and I can see that it spent less than 10 seconds on the build for each intermediate commit before cancelling them. I don't know if jitci provides this option too.