bot: dry-run, modes, separate commands for merge and bump, url-change, recipe selector

[MMesch]

Splits the version-bump bot into four named stages, exposed as a --mode flag. You can now run any of the first N stages instead of always doing everything: check → plan → edit → submit. Also skips candidate versions whose rendered URL equals the current one, which should stop the no-source-change "bump" PRs seen on commit-pinned recipes (#6698, #6570). And fixes a pre-existing indentation bug in the recipe rewriter (see second commit).

The refactor is a bit larger than strictly needed for adding the flag. The old bump_recipe_version did URL probing, hashing, git branching and PR opening in one function, so a mode flag alone would have meant a lot of if mode >= X: checks inside it. Splitting into one function per stage means the dispatcher does one check per stage, and it should be easier to change individual stages later (for example if we want to run the check stage in parallel, add a confirmation before submit, or replace URL probing with a GitHub/PyPI API call). Data flows through two small dataclasses (Candidate after check, BumpAction after plan) rather than inheritance — happy to revisit if that turns out worse.

emci/bot/bump_recipes_versions.py

• Add Mode enum (@total_ordering + a custom __lt__ that compares by definition order — the default str comparison would put edit < plan alphabetically) and four stage functions one per mode: check_bump / plan_bump / edit_bump / submit_bump.
• Add dataclasses Candidate and BumpAction.
• Rename get_new_version → find_new_version_url. Returns the URL (not the sha256), returns the recipe's current version even when no newer release is found, and skips candidate versions whose rendered URL equals the current one.
• Move the previously-inlined skip list to module scope as SKIP_RECIPES; add discover_recipes() helper.
• Pull _process_existing_bot_prs() and _checkout_target_branch() out of the dispatcher.
• Use git -c user.name=... -c user.email=... on the one commit call instead of git config --global. No writes to the user's global git config, so --mode edit works on read-only $HOME. Removes the bot_github_user_ctx / set_bot_user wrapping in this file (both still used elsewhere; git_utils.py untouched).
• Stage functions don't print anything; the dispatcher prints all output (per recipe: BUMP / no bump / error, followed by url: and — in plan/edit/submit — sha256:).

emci/__main__.py

• Add --mode {check,plan,edit,submit}, default check.
• Add --limit N (default 20). Counts successful completions of the last stage, so --limit 20 in submit mode caps at 20 real PRs.

.github/workflows/new_versions.yaml

• Pass --mode submit explicitly (default flipped to check). Otherwise unchanged.

Second commit — bot: preserve 4-space list indent when rewriting recipe.yaml
Pre-existing bug in update_recipe_version: ruamel.yaml's default sequence indent (2, offset 0) rewrote 4-space-dash list items as 2-space-dash, producing noisy indentation-only diffs on every bump for recipes with patch lists. Configure the dumper with sequence=4, offset=2 to match the repo's recipe style.

[IsabelParedes]

Testing the plan mode locally, it creates new branches and tries to commit changes. It should not, based on the comments that should only be done by the edit mode.

Switched to a new branch 'bump-raylib_5.5_to_6.0_for_origin/main'
error: gpg failed to sign the data:
gpg: skipped "emscripten-forge-bot <emscripten-forge-bot@users.noreply.github.com>": No secret key
[GNUPG:] INV_SGNR 9 emscripten-forge-bot <emscripten-forge-bot@users.noreply.github.com>
[GNUPG:] FAILURE sign 17
gpg: signing failed: No secret key

fatal: failed to write commit object

[IsabelParedes]

I disagree with this change. Most recipes already use the 2-space indentation, so changing that will create more "noise".

Also, I don't consider it noise. I think it's a way of cleaning up the recipes to make them look nicer.

I prefer the default 2-space indentation because the text starts 2-spaces from the parent key in both lists and mappings, and the dashes just act as decorators:

# Default
source:
  url: https://gh.com
  sha256: lskdflskdjf

# looks the same as
source:
- url: https://gh.com
  sha256: lskdflskdjf

With custom 4-space indentation, they would be different

source:
  url: https://gh.com
  sha256: lskdflskdjf

# not the same, even though it is the same
source:
  - url: https://gh.com
    sha256: lskdflskdjf

Not sure if I'm explaining it correctly, but let me know if you have other opinions :)

[MMesch]

I'm completely fine with 2 space. I don't have an opinion, I only saw while testing that these were additional changes introduced unrelated to bumping. I wonder though whether we should keep an explicit call here so that we don't just rely on the defaults. Maybe later on we could try to move this to a formatter for recipe PRs?

[IsabelParedes]

I think we should keep it as is. If later on we have a formatter, it could be easily added.

[MMesch]

yes, so with explicit line or without? I have a light tendency to keep it to make the choices explicit and avoid default changes leaking in but I don't mind.

[IsabelParedes]

With these modes we would still not have a complete dry-run which we can use to verify the changes that running the workflow applies to the recipes.

A complete dry-run would write the bumped recipe.yaml files, but it would not commit or create multiple branches. Ideally, all changes would remain unstaged in the current branch, that way they can be easily verified and discarded.

The current edit mode would create 20 different commits and branches locally, which would not be easy to verify.

[MMesch]

A complete dry-run would write the bumped recipe.yaml files, but it would not commit or create multiple branches.

Shall we maybe just have a no git flag? And then we could also have a --dry-run that just activates this --mode edit and --no-git? I find it useful to be able to run stuff with git as well, since that is what the bot is actually doing in the end.

[IsabelParedes]

It would be useful for you to have git enabled?

As in, creating 20 different commits in 20 different branches locally would be useful for something?

For me personally, I wouldn't find that useful. I would prefer to see all the changes in the current branch I'm working on. So then I wouldn't have to verify and delete 20 branches I don't need.

Or what sort of local workflow do you have in mind?

[IsabelParedes]

It's probably time to increase the limit to 40 or 50. We have many more packages now than when we started.

[MMesch]

OK. Maybe a separate PR for this so that we don't mix too much?

[IsabelParedes]

Yes, that works

[IsabelParedes]

Would it be possible to extract the changes that fix this issue and push them to a separate PR?

Also skips candidate versions whose rendered URL equals the current one, which should stop the no-source-change "bump" PRs seen on commit-pinned recipes (#6698, #6570).

This is a bug that affects the nightly workflow runs, so it would be good to have that merged soon.

[MMesch]

@IsabelParedes I did more changes. There is now a real dry-run. It looks like this for a bump of a specific recipe:

➜ python -m emci bot bump-recipes-versions main --recipe hypothesis --mode submit --dry-run
========================================================================
  DRY RUN — no writes, no git mutations, no gh mutations, no PRs
========================================================================
Bumping recipes in /home/matto/Projects/Conda/pixi/recipes/recipes/recipes_emscripten to main [mode=submit, dry-run]
switching from bot/dry-run to main
     [dry] would run    git stash
     [dry] would run    git fetch origin main
     [dry] would run    git checkout main
  BUMP     hypothesis: recipe @ 6.161.6 → available 6.161.7
             url:    https://pypi.io/packages/source/h/hypothesis/hypothesis-6.161.7.tar.gz
             sha256: 05dfa54c44d5c4a768c9aa8e3126824f8f9aa83f6691706abaf7fc3ee010b053
     [dry] would run    git checkout -b bump-hypothesis_6.161.6_to_6.161.7_for_main
     [dry] would write  /home/matto/Projects/Conda/pixi/recipes/recipes/recipes_emscripten/hypothesis/recipe.yaml
     [dry]   --- /home/matto/Projects/Conda/pixi/recipes/recipes/recipes_emscripten/hypothesis/recipe.yaml
     [dry]   +++ /home/matto/Projects/Conda/pixi/recipes/recipes/recipes_emscripten/hypothesis/recipe.yaml
     [dry]   @@ -2,3 +2,3 @@
     [dry]      name: hypothesis
     [dry]   -  version: 6.161.6
     [dry]   +  version: 6.161.7
     [dry]   
     [dry]   @@ -10,3 +10,3 @@
     [dry]    - url: https://pypi.io/packages/source/${{ name[0] }}/${{ name }}/${{ name }}-${{ version }}.tar.gz
     [dry]   -  sha256: e276f5705cb929ff059785db8fd3a5074c9081529944833a0a4b4f6b9b9303dd
     [dry]   +  sha256: 05dfa54c44d5c4a768c9aa8e3126824f8f9aa83f6691706abaf7fc3ee010b053
     [dry]   
     [dry] would run    git add /home/matto/Projects/Conda/pixi/recipes/recipes/recipes_emscripten/hypothesis
     [dry] would run    git -c user.name=emscripten-forge-bot -c user.email=emscripten-forge-bot@users.noreply.github.com commit -m 'Update hypothesis from 6.161.6 to 6.161.7'
     [dry] would run    git checkout bot/dry-run --force
     [dry] would run    git push -u origin bump-hypothesis_6.161.6_to_6.161.7_for_main --force
     [dry] would run    gh repo set-default emscripten-forge/recipes
     [dry] would run    gh pr create -B main --title 'Update hypothesis from 6.161.6 to 6.161.7' --body 'Beep-boop-beep! Whistle-whistle-woo!' --label Automerge
     [dry] would run    git branch -D bump-hypothesis_6.161.6_to_6.161.7_for_main
Total (submit): 1
========================================================================
  DRY RUN complete — nothing was actually executed
========================================================================

And like this for merging open PRs (which I split out into an independent subcommand):

➜ python -m emci bot merge-open-prs main --dry-run
========================================================================
  DRY RUN — no gh mutations
========================================================================
Merging open bot PRs on main [dry-run]
Checking opened PRs and merge them if green!
PR #6814  (numcodecs)
Labels for PR 6814: {'labels': [{'id': 'LA_kwDOG-uhD88AAAABTvTcHQ', 'name': 'Needs Human Review', 'description': 'The CI is not passing, automerge is disabled', 'color': 'd93f0b'}, {'id': 'LA_kwDOG-uhD88AAAABUoM2_g', 'name': 'Automerge', 'description': 'The PR will be automatically merged if CI is green', 'color': '49D06A'}]}
     [dry] would run    gh pr edit 6814 --add-label 'Needs Human Review'
     [dry] would run    gh pr comment 6814 --body 'Either the CI is failing, or the recipe is not tested. I need help from a human.' --edit-last
...

[MMesch]

We don't necessarily need mode anymore with this, I guess. Maybe it's still useful to actually execute the stages locally and it's not a big overhead to keep though. LMK.

[MMesch]

Should maybe activate dry-run by default to avoid accidental things happening.

[MMesch]

closing for now. @IsabelParedes taking over directly.