bonsaiPR: your weekly build with PRs merged (as much as possible)

falken10vdl · October 2025

Following discussion https://community.osarch.org/discussion/comment/26664 please find here a repository with all possible merges of PRs done automatically.
I will run it weekly and keep the last 4 weeks.
I hope this serves for users to provide feedback on the available PRs. Note that if the build does not work, please reach out to the PR authors or me (I will be able to test on linux or windows).
The build is following the PRs in decreasing number order so some PRs are not succeeding due to other previous merged PRs.
If you guys think that the PRs should follow other order, let me know so the build is done accordingly.
I have replaced (hopefully everywhere were it is needed) the word "bonsai" with the word "bonsaiPR" so it should be simple to know that this is the bonsaiPR addon not to confuse with bonsai.
The idea is to have the possibility to disable one and enable the other whenever needed

Of course one should disable one before enabling the other.
Here is the project:
https://github.com/falken10vdl/bonsaiPR
Under releases you have the zips for the addons:
https://github.com/falken10vdl/bonsaiPR/releases

The full report on how each one of the PR was merged is in the assets as README log file. I have provided the list by author so it is simpler for each PR author to check them.
I hope you find it useful.
Cheers!

falken10vdl · October 2025

If the core developers find it useful maybe this can be hosted directly in ifcOpenShell github page.
Cheers!

theoryshaw · October 2025

Very cool. Would it be possible to maintain a pullable branch that has all these merged as well?
That makes testing easier, as you can check out at certain dates, etc.

Moult · October 2025

This is really, really good! Let's see how people use it, and if it works well it'll be great to use an official ifcopenshell org name in Github and link to it in docs.

falken10vdl · October 2025

@theoryshaw I have updated the project https://github.com/falken10vdl/bonsaiPR
On a weekly basis I will create a branch that you can pull with the merges done:

The structure now has an automation folder and source folder.

The automation holds all the scripts that I run to make these so anyone can try it locally if he/she wants.
The source directory has the code for bonsai with the successfully merged PRs so one can fetch it to see why the not successful ones did not make it

Cheers!

theoryshaw · October 2025

Cool, one last request, is it possible to have this branch, just be a fork of the IfcOpenShell repo?
That way, all the symlinks work, as setup in our development environments.
and we can check out from one branch to another easily.

falken10vdl · October 2025

@theoryshaw This was an overhaul :) I found out that github does not allow me to have two forks from the same project IfcOpenShell/IfcOpenShell so I had to use the fork I was using to create my own PRs to also have weekly builds of the merged PRs:

So now the falken10vdl/bonsaiPR (https://github.com/falken10vdl/bonsaiPR) just holds the addons as assets (and the automation code for whoever wants to take a look) that can be used by end users and the branches in falken10vdl/IfcOpenShell can be used by the PR authors

Cheers!

theoryshaw · October 2025

So cool!... so for the hassle. :)
...
Would it be possible not to merge the 'drafts'?
https://github.com/IfcOpenShell/IfcOpenShell/pulls?q=is:pr+is:open+is:draft
There are times, i create a PR with broken code, to try and just get some help. I wouldn't want to unnecessarily add that noise to this 'bleeding_edge' branch.
...
I wonder too, as maintainers, perhaps we should convert the PR's to 'drafts' before explicitly being told by the PR's author, they are ready to pull.

falken10vdl · October 2025

@theoryshaw Good feedback! I just added those in the SKIPPED section. If you go to a release it looks now like this:

Cheers!

sjb007 · October 2025

@theoryshaw said:
I wonder too, as maintainers, perhaps we should convert the PR's to 'drafts' before explicitly being told by the PR's author, they are ready to pull.

I wonder why it isn't possible to configure github to force all new PR's to draft by default. Then the submitter can set it to Ready for Review for review and merge. See https://github.com/orgs/community/discussions/6943 - 4 years... 🤷

theoryshaw · October 2025

Question to AI: Just thinking out loud.... Let's say we create this bleeding edge branch for bonsaibim and ifcopenshell. And i use this bleeding edge on the projects .ifc projects posted here: https://hub.openingdesign.com/ Could there be a way to automatically test incoming .ifc files with something like the buildingSMART validator, or the like. That way, if the .ifc file becomes invalid, we'd know right away the bleeding edge branch codified the .ifc incorrectly.

Chat with AI...
click to expand

Ohhh — yes. ✅

This is a brilliant idea and exactly the kind of “safety net” that makes a bleeding_edge branch sustainable:

fast merges,
real projects being tested automatically,
and early warnings when the branch starts producing invalid IFC.

And yes — what you’re describing can absolutely be automated.

Let’s break it down step by step:

🧪 What You’re Proposing

Maintain a bleeding_edge branch for BonsaiBIM and IfcOpenShell.
Regularly test real-world .ifc models (e.g. from hub.openingdesign.com).
Run an IFC validation process automatically (e.g. using the buildingSMART IFC Validation Service or similar tools).
If the validation fails → alert maintainers, or even automatically flag the offending PR.

🧰 How You Could Set This Up

1. Establish a Model Test Suite

Select a representative set of real .ifc files from the OpeningDesign hub.
Store them either:
- In a dedicated repo (e.g. bonsaibim-ifc-tests)
- Or reference their URLs if they can be reliably fetched.
This becomes your “canary project set.”

📝 Tip: Start with 3–5 small to medium IFCs, but aim for variety (architectural, MEP, different schema versions, etc.).

2. Trigger CI/CD on Every Bleeding Edge Commit

Use GitHub Actions (or Forgejo CI if you’re self-hosting) to run a workflow when:
- PRs are merged into bleeding_edge
- Or on a nightly schedule
The workflow will:
1. Pull the latest bleeding edge build.
2. Download/open each .ifc file in the canary set.
3. Run a validation process.

3. Validation Options

🧭 Option A: Official IFC Validator

buildingSMART IFC Validation Service provides:
- A public web validator (for manual checks)
- APIs (for programmatic use, though you may need credentials / setup)
CI can POST IFC files to the validator and check the returned report for errors.

✅ Pros: authoritative validation.
⚠️ Cons: external dependency, may need rate limiting or API agreement.

🧰 Option B: Local / CLI Validation Tools

Use IfcOpenShell’s built-in validation utilities or something like:
- ifcopenshell.validate() in Python (basic schema checks).
- xBIM Toolkit (on Windows, C#).
- BlenderBIM Add-on’s validation features (headless mode).

✅ Pros: runs locally in CI, no external dependency.
⚠️ Cons: may not be as rigorous as buildingSMART’s validator.

🧪 Option C: Hybrid

Run fast local checks on every commit.
Run the full buildingSMART validation nightly or weekly.
This balances speed and depth.

4. Reporting the Results

If a validation fails:
- Post a GitHub/Forgejo status check with pass/fail.
- Link to the report (e.g., “Geometry invalid: entity X missing required attribute”).
- Optionally: open an issue or comment on the PR that last touched the code.

5. Optional Enhancements

Diff IFCs: run before/after comparisons to detect unexpected structural changes.
Schema evolution tests: ensure output is still valid for IFC2x3, IFC4, IFC4.3, etc.
Performance metrics: detect if bleeding edge made models heavier or slower to export.

⚡ Result

If any bleeding edge commit or PR breaks IFC validity, you’d know:

within minutes, if it’s caught by CI
or within a day, if it’s caught by a scheduled nightly run
→ That gives you fast feedback and keeps main clean.

And — since you’re using real projects from OpeningDesign, your test suite is not just synthetic. It reflects actual production use, which makes it far more meaningful than toy tests.

brunopostle · October 2025

@theoryshaw A better solution would be server-side validation of every git commit to an IFC project. Ideally this would be integrated into forgejo, but it can also be done now with normal Github CI tools - ifcopenshell with the validator is just a pip install.

falken10vdl · October 2025

@brunopostle Can you elaborate a little bit more? what is the difference between ifc openshell validator and buildingSMART validator?
Thanks!

brunopostle · October 2025

@falken10vdl I believe they are the same thing.

We have a git based workflow where Bonsai can commit changes and push IFC files to remote git repositories. With normal source code you can configure a lint checker in Github to check all commits and pull requests, we should do the same and validate IFC data with every commit (similarly, drop some IDS files into the repository and automatically check the model with these).

brunopostle · October 2025

Ok, that was easy. In your IFC Git repository create a file called .github/workflows/ifc-lint.yml and put this in it:

name: IFC Validation

on:
  push:
  pull_request:

jobs:
  lint-ifc:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout repository
        uses: actions/checkout@v3

      - name: Set up Python
        uses: actions/setup-python@v4
        with:
          python-version: '3.x'

      - name: Install ifcopenshell
        run: |
          pip install pytest
          pip install ifcopenshell

      - name: Run IFC lint checks
        run: |
          set -e
          shopt -s globstar nullglob
          for file in **/*.ifc; do
            echo "Validating $file..."
            python3 -m ifcopenshell.validate --rules "$file"
          done

brunopostle · October 2025

brunopostle · October 2025

..and here's another one: automatic IDS checking.

Create an IDS folder in the root of your repository and add some IDS files that you want to use to check your IFC model, as many as you like.

Create a .github/workflows/ids-lint.yml file with this content:

name: IDS Compliance Check

on:
  push:
  pull_request:
  workflow_dispatch:

jobs:
  ids-lint:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout repository
        uses: actions/checkout@v3

      - name: Set up Python
        uses: actions/setup-python@v4
        with:
          python-version: '3.10'

      - name: Install ifctester
        run: pip install ifctester

      - name: Run ifctester for all IDS/IFC combinations
        run: |
          shopt -s globstar nullglob
          ids_files=(IDS/**/*.ids)
          ifc_files=(**/*.ifc)

          if [ ${#ids_files[@]} -eq 0 ]; then
            echo "No IDS files found in IDS/"
            exit 1
          fi

          if [ ${#ifc_files[@]} -eq 0 ]; then
            echo "No IFC files found"
            exit 1
          fi

          failed=0

          for ids in "${ids_files[@]}"; do
            for ifc in "${ifc_files[@]}"; do
              echo "▶ Validating $ifc with $ids"
              if ! python3 -m ifctester --no-color "$ids" "$ifc"; then
                echo "❌ Validation failed for $ifc with $ids"
                failed=1
              fi
            done
          done

          if [ "$failed" -ne 0 ]; then
            echo "❌ Some IFC/IDS validations failed."
            exit 1
          else
            echo "✅ All IFC/IDS validations passed."
          fi

..and here is what the results look like in Github, formatting is a bit texty, and ifctester doesn't seem to return pass/fail:

brunopostle · October 2025

I realise I hijacked this post, but then provided something useful that has been often desired - could someone with admin permission split this into a separate post on Continuous Integration (CI) for IFC projects ?

theoryshaw · October 2025

I would keep it in. I asked, and think it aligned with finding ways to improve the testing of this bleeding_edge branch. @falken10vdl that okay?

falken10vdl · October 2025

@brunopostle @theoryshaw . For me it is fine. Thanks a lot @brunopostle for your guidance on setting proper checks in CI pipeline.
Cheers!

theoryshaw · October 2025

I propose marking all the PR's as drafts, and then share the following, to expliciting ask the PR's authors if their PR is ready to be pulled.
Thoughts?

Bleeding Edge Testing Branch – Contributor Expectations

TL;DR: If your PR is ready to be pulled into the main branch, please click the “Ready for review” button.

We’re trying something new to keep great contributions from going stale.

🧭 The Problem

Many excellent PRs are submitted by contributors, but core maintainers have limited time for timely reviews. As a result, PRs often sit unmerged, contributors lose momentum, and valuable work risks being forgotten.

🛠️ The Solution: `bleeding_edge` Branch

We’ve created a bleeding_edge branch that automatically merges all PRs marked as ready.
“Ready” simply means the author has reviewed their own work and believes it’s fit for production.

All incoming PRs will initially be marked as Draft.
When your PR is ready, just click “Ready for review”.
- If you're a returning contributor, and already know of this approach, you can also just say in your PR comments that your PR is ready to be pulled.
Your PR will then be automatically merged into the bleeding_edge branch.
Power users can install this weekly build to test multiple PRs together, helping catch issues earlier and reducing the load on core developers.

👉 Download bleeding edge builds

This approach allows us to:

Keep contributions fresh
Accelerate feedback loops
Empower the community to help stabilize new features

Thanks for helping make this project better.

steverugi · October 2025

where is the active link please?
I was under the impression the process would be the same as the 'unstable' one
EDIT
OK it's here:

EDIT 2
@falken10vdl FYI contrary to what indicated in the list of merged PR #7077 doesn't seem to be implemented:

thanks

falken10vdl · October 2025

@steverugi Weird. I just tried it:

What OS are you using? I am using Linux.
Cheers!

steverugi · October 2025

@falken10vdl
I was looking for PR #7077: Add mass and time unit to new project wizard panel
windows

falken10vdl · October 2025

@steverugi Sorry. I think the windows build after I tried to remove DRAFT PRs did not work as expected.
I have removed BonsaiPR Weekly Build - 2025-10-14.
Can you please try with BonsaiPR Weekly Build - 2025-10-13.? https://github.com/falken10vdl/bonsaiPR/releases/tag/v0.8.4-alpha251013

Cheers!

falken10vdl · October 2025

I believe the automation chain is now working properly. I just run it and hopefully you will see new branches every sunday.
This is the latest:
https://github.com/falken10vdl/bonsaiPR/releases/tag/v0.8.4-alpha251021
with these PRs added to enjoy testing!

Cheers!

theoryshaw · October 2025

Hi, @falken10vdl
I created a PR, it it makes sense: https://github.com/falken10vdl/bonsaiPR/pull/2
Cheers.

falken10vdl · October 2025

@theoryshaw That is really cool!
Thanks!

theoryshaw · November 2025

Just FYI, I changed a number of PR's to drafts, and shared the following blurb...
...

Hi @
Just an fyi, i changed this PR to a 'draft'.
We’re trying something new to keep great contributions from going stale.
Logic here: https://github.com/falken10vdl/bonsaiPR/blob/main/PR_workflow.md
Originally discussed here and here.

TL;DR: If your PR is ready to be pulled into the main branch, please click the “Ready for review” button.

sjb007 · November 2025

I don't know if this is a good idea to include in the bleeding edge build, but it would be useful to know if a PR is failing to merge into bleeding edge because it is conflicting with other PR's or if it fails to merge with the head of vanilla Bonsai main because it is stale. People could be confused if their PR is marked in edge as failing to merge, but as far as they are concerned, there are no conflicts in their up-to-date local repo.

falken10vdl · November 2025

Good poibt @sjb007 ! Let me add some automation to check each pr individually against the head and add that information. Most of them probably are fine to merge against the head but it is just a conflict with some other pr inthe same code area. I have actually combined a few of my PRs to avoid this issue and have them all merged... ;)
Cheers!

bonsaiPR: your weekly build with PRs merged (as much as possible)

Comments

🧪 What You’re Proposing

🧰 How You Could Set This Up

1. Establish a Model Test Suite

2. Trigger CI/CD on Every Bleeding Edge Commit

3. Validation Options

🧭 Option A: Official IFC Validator

🧰 Option B: Local / CLI Validation Tools

🧪 Option C: Hybrid

4. Reporting the Results

5. Optional Enhancements

⚡ Result

Bleeding Edge Testing Branch – Contributor Expectations

🧭 The Problem

🛠️ The Solution: bleeding_edge Branch

🛠️ The Solution: `bleeding_edge` Branch