Hi @falken10vdl
I tried and I failed to get clean links on the report. Can you help? :)
Also the whole Conflicting files: and Possible breaking commits: is missing.
I basically use BonsaiPR for day-to-day work now, and the one big piece so far is that Freestyle seems to be broken in 5.1 https://github.com/IfcOpenShell/IfcOpenShell/issues/7657
I use that quite a bit on my drawings.
As such, I'm partial to 4.5 and 5.0 for now, if that's okay.
I remmber it was doing it in two passes. One oldest to newest PR numbering and the other newest to oldest. So you get two releases just in case you are more interested in the newer or in the older PRs.
Cheers!
I remmber it was doing it in two passes. One oldest to newest PR numbering and the other newest to oldest. So you get two releases just in case you are more interested in the newer or in the older PRs.
Cheers!
Ah, gotcha! Yes i can see how that's helpful. Would it be a good idea to have some indicator on the report, as such?
@theoryshaw said:
Hi @falken10vdl
I tried and I failed to get clean links on the report. Can you help? :)
Also the whole Conflicting files: and Possible breaking commits: is missing.
It is now fixed (the variable with the link was already in markdown format so it was "markdowned" twice). I have also added some workding about the two releases:
@theoryshaw Actually I was looking to the list of PRs and saw that they were ordered in the report by "updated_at". I think that is also a good ordering for merging the PRs, right? So now we have each release having three possibilities: Ascending [asc] /Descending [desc] PR number and descending "updated_at" [upd].
Cheers!
@theoryshaw said:
Great idea!
Were you able to figure out why Conflicting files: and Possible breaking commits: was missing?
Sorry I missed that. Now it is fixed. The parsing function was not following the format of the report generation.
Note that the creation of releases (asc, desc, upg) is only triggered if there is any benefit:
1. Ascending [asc]: Always runs. Merges all open PRs lowest PR# first
2. Descending [desc]: Only considered if the ascending build had at least one PR skipped due to conflict with another PR (i.e. it merges cleanly against the base branch alone, but conflicts when merged together with other PRs).
3. By-Updated [upd]: Only considered if the ascending build had conflict-skipped PRs AND after the descending build there are still some PRs unresolved (i.e. still_skipped = skipped_by_asc - resolved_by_desc).
So the cases would be:
Now assets for blender 5.1 (py313) are also created. If you select automated updates the index.json file should properly find the right one based on the blender version and architecture
Cheers!
Sooo... which is the preferred one for people to use? [asc], [desc] or [upd]? And is that the same as in the index.json? Or does index.json just list the last release posted?
The upload script updates and commits index.json after each build that completes (each of the up to 3). So index.json always points to the last release posted in that run:
If no conflicts → index.json = ascending build
If descending helped → index.json = descending build
If by-updated also ran → index.json = by-updated build
This means the entry in index.json (currently v0.8.5-alpha2604081058) represents whichever merge strategy was the last one that produced a release — it doesn't track or distinguish between them, it just overwrites with the latest.
The releases page on GitHub would have all 3 separate releases with different timestamps (e.g., ...1058, ...1102, ...1118), but Blender users via the extension repo only ever see/install the one index.json reflects. I was just copying how the bonsai updated workflow works. I do not knwo if Blender supports choosing among options... Let me find out...
It looks that Blender's extensions do not support user-slectable variants. We could add distinct IDs (bonsaiPR_asc, bonsaiPR_desc, bonsaiPR_upd) but it would be a little bit messy and we would need then to generate all of them always or otherwise someone that had selected _upd might not receive updates for long if that one happens not to be available for a while.
What are your thoughts?
Well I don't know how many are using the bonsaiPR repo as their daily driver, or if they are using the index.json for automatic updates. It could certainly be confusing however. Not easily knowing which version is installed, presumably the PR's successfully applied would differ between the variants, meaning features flickering on and off.
I only really use this fork in a test install to check things out like theoryshaws recent work, so it's not really a major issue for me. Maybe if there's someone using it as a daily they could chime in here.
I don't really install any way, I check out via git and use the 'live development' environment.
I use it daily--test through use. :) No time, to test through testing. :)
Cheers
I have both bonsai unstable and bonsaiPR installed with automatic updates for both. I have also the cloned src of both with the script dev_environment_vscode_config.py run so I can set breakpoints and debug in either one.
Once I needed to download the [asc] zip file and install it since the PR I wanted to check was not available in the [desc].
Cheers!
@theoryshaw Wow! You tested the prompt to get #7802 updated so it does not conflict with #7003. I am wondering how many PRs conflicts could be solved this way :)
How should bleeding-edge builds handle PRs broken by upstream main-branch activity?
The BonsaiPR build system aggregates open PRs from IfcOpenShell into installable builds, so contributors and testers can use work-in-progress features before they're officially merged. One recurring challenge I'd like the community's input on:
A contributor opens a PR. It merges cleanly against v0.8.0. It gets included in builds. Then, someone with direct push access lands a commit on v0.8.0 that touches the same files — and suddenly the contributor's PR no longer merges cleanly. The PR itself hasn't changed. The contributor did nothing wrong. But now they bear the full burden of rebasing.
This happens regularly, and raises some questions I don't have a clear answer to:
Whose responsibility is the rebase? Should the contributor always be expected to keep their branch current, even when the conflict was caused entirely by upstream activity they had no part in? Or does some responsibility fall on the person who introduced the breaking change?
Should breaking commits be flagged? The build report now identifies which specific upstream commit broke each PR, and who authored it. Is it appropriate to surface that information publicly (e.g., as a comment on the affected PR), or does that create unnecessary friction?
I'm not trying to assign blame — people with direct push access are usually fixing real things. But I want a policy that feels fair to contributors who are going through the PR process in good faith. Curious what norms other projects have developed here, or what this community thinks is reasonable.
Traditionally it is up to the submitter to make it fit. But while the AI agents are cheap it is easy to ask the bot to fix the branch before merging (you can also ask it to split it into features to merge separately etc..).
Having just bought anthropic tokens at full price I can say we are all in for a shock when these coding agents stop being a loss leader.
@brunopostle said
Having just bought anthropic tokens at full price I can say we are all in for a shock when these coding agents stop being a loss leader.
Am I too old to start thinking for my self again 🙃
Comments
@theoryshaw now the script building the addon first pulls bonsaiPR from github to fetch the latest.
Cheers!
Hi @falken10vdl
I tried and I failed to get clean links on the report. Can you help? :)
Also the whole
Conflicting files:andPossible breaking commits:is missing.Another odd thing it does is, every other build seems to have additional skipped PR's even though nothing has changed...
I tired to address it here: https://github.com/falken10vdl/bonsaiPR/commit/c8660ee7be67d5fb404d60a3a2c05f589a262c6f
but was a no-go.
@theoryshaw sure! One question... Should we move to blender 5.1 (so python 3.13)?
Thanks!
I basically use BonsaiPR for day-to-day work now, and the one big piece so far is that Freestyle seems to be broken in 5.1
https://github.com/IfcOpenShell/IfcOpenShell/issues/7657
I use that quite a bit on my drawings.
As such, I'm partial to 4.5 and 5.0 for now, if that's okay.
I remmber it was doing it in two passes. One oldest to newest PR numbering and the other newest to oldest. So you get two releases just in case you are more interested in the newer or in the older PRs.
Cheers!
Ah, gotcha! Yes i can see how that's helpful. Would it be a good idea to have some indicator on the report, as such?
It is now fixed (the variable with the link was already in markdown format so it was "markdowned" twice). I have also added some workding about the two releases:
Cheers!
@theoryshaw Actually I was looking to the list of PRs and saw that they were ordered in the report by "updated_at". I think that is also a good ordering for merging the PRs, right? So now we have each release having three possibilities: Ascending [asc] /Descending [desc] PR number and descending "updated_at" [upd].
Cheers!
Great idea!
Were you able to figure out why
Conflicting files:andPossible breaking commits:was missing?Sorry I missed that. Now it is fixed. The parsing function was not following the format of the report generation.
Note that the creation of releases (asc, desc, upg) is only triggered if there is any benefit:
1. Ascending [asc]: Always runs. Merges all open PRs lowest PR# first
2. Descending [desc]: Only considered if the ascending build had at least one PR skipped due to conflict with another PR (i.e. it merges cleanly against the base branch alone, but conflicts when merged together with other PRs).
3. By-Updated [upd]: Only considered if the ascending build had conflict-skipped PRs AND after the descending build there are still some PRs unresolved (i.e. still_skipped = skipped_by_asc - resolved_by_desc).
So the cases would be:
Cheers!
Now assets for blender 5.1 (py313) are also created. If you select automated updates the index.json file should properly find the right one based on the blender version and architecture
Cheers!
Sooo... which is the preferred one for people to use? [asc], [desc] or [upd]? And is that the same as in the index.json? Or does index.json just list the last release posted?
@sjb007
What index.json actually reflects:
The upload script updates and commits index.json after each build that completes (each of the up to 3). So index.json always points to the last release posted in that run:
This means the entry in index.json (currently v0.8.5-alpha2604081058) represents whichever merge strategy was the last one that produced a release — it doesn't track or distinguish between them, it just overwrites with the latest.
The releases page on GitHub would have all 3 separate releases with different timestamps (e.g., ...1058, ...1102, ...1118), but Blender users via the extension repo only ever see/install the one index.json reflects. I was just copying how the bonsai updated workflow works. I do not knwo if Blender supports choosing among options... Let me find out...
Cheers!
It looks that Blender's extensions do not support user-slectable variants. We could add distinct IDs (bonsaiPR_asc, bonsaiPR_desc, bonsaiPR_upd) but it would be a little bit messy and we would need then to generate all of them always or otherwise someone that had selected _upd might not receive updates for long if that one happens not to be available for a while.
What are your thoughts?
Well I don't know how many are using the bonsaiPR repo as their daily driver, or if they are using the index.json for automatic updates. It could certainly be confusing however. Not easily knowing which version is installed, presumably the PR's successfully applied would differ between the variants, meaning features flickering on and off.
I only really use this fork in a test install to check things out like theoryshaws recent work, so it's not really a major issue for me. Maybe if there's someone using it as a daily they could chime in here.
I don't really install any way, I check out via git and use the 'live development' environment.
I use it daily--test through use. :) No time, to test through testing. :)
Cheers
I have both bonsai unstable and bonsaiPR installed with automatic updates for both. I have also the cloned src of both with the script dev_environment_vscode_config.py run so I can set breakpoints and debug in either one.
Once I needed to download the [asc] zip file and install it since the PR I wanted to check was not available in the [desc].
Cheers!
Created an AI prompt to help resolve conflicts between other PR's....
https://github.com/falken10vdl/bonsaiPR/blob/3410d1800a8b374abb4fd3e48a05b4e3379ee724/prompts/resolve conflicts with other PRs.md
@falken10vdl refined the prompt...
https://github.com/falken10vdl/bonsaiPR/blob/main/prompts/resolve conflicts with other PRs.md
Also, started an ongoing log, for the resolution of the PR conflicts...
https://github.com/falken10vdl/bonsaiPR/blob/main/logs/conflict-resolutions.md
@theoryshaw Wow! You tested the prompt to get #7802 updated so it does not conflict with #7003. I am wondering how many PRs conflicts could be solved this way :)
How should bleeding-edge builds handle PRs broken by upstream main-branch activity?
The BonsaiPR build system aggregates open PRs from IfcOpenShell into installable builds, so contributors and testers can use work-in-progress features before they're officially merged. One recurring challenge I'd like the community's input on:
A contributor opens a PR. It merges cleanly against
v0.8.0. It gets included in builds. Then, someone with direct push access lands a commit onv0.8.0that touches the same files — and suddenly the contributor's PR no longer merges cleanly. The PR itself hasn't changed. The contributor did nothing wrong. But now they bear the full burden of rebasing.This happens regularly, and raises some questions I don't have a clear answer to:
I'm not trying to assign blame — people with direct push access are usually fixing real things. But I want a policy that feels fair to contributors who are going through the PR process in good faith. Curious what norms other projects have developed here, or what this community thinks is reasonable.
Traditionally it is up to the submitter to make it fit. But while the AI agents are cheap it is easy to ask the bot to fix the branch before merging (you can also ask it to split it into features to merge separately etc..).
Having just bought anthropic tokens at full price I can say we are all in for a shock when these coding agents stop being a loss leader.
Am I too old to start thinking for my self again 🙃