Conversation
The old workflow opened a pull request and left the merge to a human. The first one was merged with "squash", which copied main's content into develop as one ordinary commit and dropped its history. Git then had no way to know develop already held those changes, so every later back-merge tried to re-apply 236 commits whose content was already there: 67 conflicting files on a merge that should have been a formality. A back-merge carries no decision, so it no longer waits for one. The workflow fast-forwards develop when develop has nothing of its own, and otherwise makes the merge commit itself and pushes it. A pull request is still opened, but only when the work genuinely cannot be done unattended -- a real conflict, or a branch rule refusing the push -- and its body now says in capitals not to squash it. develop itself was repaired separately: main merged in with its content taken throughout, verified byte-identical to main's tree, which lost nothing because develop carried no work of its own.
The previous commit tried to have the workflow push the merge to develop. That cannot work: `develop` is protected and refuses pushes outright -- "Changes must be made through a pull request". The attempt is on record in the run it declined. So the pull request stays; the person goes. The workflow now turns on auto-merge with the MERGE method, and GitHub merges the PR once its required checks pass. Nobody picks a method, so the squash that broke this once cannot happen by accident. Where auto-merge is unavailable the run warns and the PR body says, in capitals, not to squash it. This needed `allow_auto_merge` on the repository, which was off. Permissions drop to `contents: read`, since nothing pushes any more.
A dependency bump is ordinary work, and ordinary work enters through `develop` per Branching in CONTRIBUTING.md. Opening them against `main` put them straight onto the release branch. Both ecosystems move, npm and github-actions. The one already open against `main` stays there; Dependabot does not retarget an existing pull request.
This raced, and CI on develop lost the race: the job could finish between the poll that confirms it is running and the command that expects to be refused, and then there was nothing to refuse. `--max-cpu 1` gives the first job a single thread over 57 seconds of audio, which widens the window by about four times. The failure now says what the first job was doing. "expected not 0" cannot tell apart the three ways this goes wrong -- the job finished early, it died, or the lock was not honoured -- and the CI run that found it recorded none of that, so the cause is still unknown. Next time it will not be. The flag reaches the detached child (transcribeChildArgs forwards --max-cpu), and that it becomes `-t 1` on the engine is asserted in resources.spec.ts.
lorem-dev
enabled auto-merge (rebase)
September 8, 2026 19:42
lorem-dev
self-requested a review
September 8, 2026 19:44
lorem-dev
disabled auto-merge
September 8, 2026 19:45
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Automated back-merge of
mainintodevelop. Auto-merge is on, so this merges itself once the required checks pass.Latest commit on main:
cf5049c- test: keep the first job busy while the lock test needs itTriggered by push to
mainin workflowBack-merge main -> developrun34261764555.Merge this with a MERGE COMMIT, not a squash. A squash copies main's content without its history, so git stops knowing that develop already contains it and every later back-merge conflicts on files nobody touched. That is what happened once already; see the comment at the top of
.github/workflows/backmerge.yml.