The script 00_clone_merge_and_create_branch.py is now updated and I have run the whole chain so a new release has been created:
Unfortunately (well fortunately... :) ) there are no Skipped (conflicts with other PRs). Eventually we will see PRs moving out of the draft status but still skipped due to conflict with others but not with the base. So Failed only gives a warning that the PR needs actually to be rebased.
Thanks!
Hi @falken10vdl,
Would it be possible to push the current list to the bonsaiPR repo? That way, peeps can do a pull request to either add, or remove from list. EXCLUDED=comma_separated_list_of_pr_numbers_to_exclude
...
Also, is there a way to automatically create a release every time there's either a new or modified PR? Or are you still manually triggering the build, and this would be too much overhead?
I'm not sure if the information is there and I just can't see it, but would it be possible to have the last commit hash of the source repository in the release page somewhere. Not really important as I can figure it out by comparing the data of the release and the dates of the commits in the source repo - just a "nice to have".
Hi @falken10vdl,
Would it be possible to push the current list to the bonsaiPR repo? That way, peeps can do a pull request to either add, or remove from list.
EXCLUDED=comma_separated_list_of_pr_numbers_to_exclude
...
Changed. Only 5452 is excluded as it breaks execution. The ones excluded appear in the failed list:
Also, is there a way to automatically create a release every time there's either a new or modified PR? Or are you still manually triggering the build, and this would be too much overhead?
I have a cron running on sundays and sometimes I trigger manually if I have made some change and want to propagate it.
Let me find out if I can get this done whenever there is a a new/modified PR.
Cheers!
I'm not sure if the information is there and I just can't see it, but would it be possible to have the last commit hash of the source repository in the release page somewhere. Not really important as I can figure it out by comparing the data of the release and the dates of the commits in the source repo - just a "nice to have".
@sjb007 Indeed! Thanks for the feedback! I have added a link after the title to the last commit of the base ifcopenshell before merging the PRs.
Also, is there a way to automatically create a release every time there's either a new or modified PR? Or are you still manually triggering the build, and this would be too much overhead?
I have now a script that runs hourly and checks for changes in PRs If there is a change a new release is created. Note that I have added the hour-minute after the date info.
Cheers!
@theoryshaw When the release is created, first the 00_clone_merge_and_create_branch.py script creates the branch. Ex:
Let me add a link to this branch in the release page after the link to the base branch commit.
Thanks!
I have implemented automated updates in blender for BonsaiPR in the same way it is done for bonsai unstable repo. That way no need to keep downloading manually zip files and remove old ones with new ones.
You have the instructions in the README of https://github.com/falken10vdl/bonsaiPR:
I think this will allow for easier switching between both.
Cheers!
Since some time there are PRs that are skipped due to "Conflict with other PRs. Merges cleany with base", I have implemented a second pass. If there are any of those PRs, a new release is created going form newest to oldest PR.
This allows to have also an addon with the latest PRs with more probability to be succesfully merged.
You can see it by looking to the order in which the PRs were merged.
Hopefully this allows for testing the newest PRs regardless of the older ones.
Ex: https://github.com/falken10vdl/bonsaiPR/releases/tag/v0.8.5-alpha2601172116
Triggered the creation of a new release in reverse order for which now those PRs are successfully merged and older ones not: https://github.com/falken10vdl/bonsaiPR/releases/tag/v0.8.5-alpha2601172130
I would be nice if we could log the date and perhaps the commit that broke a pending PR.
Would think this would help the contributors to try and reconcile their corresponding commits.
What do you guys think about adding a new section(s) to this page: https://docs.bonsaibim.org/guides/development/installation.html about forks, so that there is a little explanation and more exposure about how to install BonsaiPR (and also highlight other "fork" branches like Saikei and 4DBonsai).
@theoryshaw said:
I would be nice if we could log the date and perhaps the commit that broke a pending PR.
Would think this would help the contributors to try and reconcile their corresponding commits.
Let me dig a little bit. Si some repor on the merging conflict details, right?
cheers!
@theoryshaw said:
I would be nice if we could log the date and perhaps the commit that broke a pending PR.
Would think this would help the contributors to try and reconcile their corresponding commits.
Let me dig a little bit. So some report on the merging conflict details, right?
cherry!
@Moult said:
What do you guys think about adding a new section(s) to this page: https://docs.bonsaibim.org/guides/development/installation.html about forks, so that there is a little explanation and more exposure about how to install BonsaiPR (and also highlight other "fork" branches like Saikei and 4DBonsai).
Sorry I missed this post. It is done!
Sorry I only xposed a .env example as I have the github token info in the local clone that builds the bonsaiPR addons (I do not use actions to build them, just make locally and then upload).
Cheers!
I think there was something between..
BonsaiPR v0.8.5-alpha260310-ed52628 Pre-release
and
BonsaiPR v0.8.5-alpha260310-8bbeefa Pre-release
..that prevented BPR from enabling.
Could this 'conflict analysis' also be applyed to ... Skipped - Conflict with other PRs. as well?
Would think it would help @Dimitris understand why his PR #7342 is not being merged into BonsaiPR.
Conflicting files — each file path is now a markdown link to the file on GitHub at IfcOpenShell/IfcOpenShell/blob/v0.8.0/<path>.
Possible breaking commits — the short commit hash is now a markdown link to IfcOpenShell/IfcOpenShell/commit/<hash>, with the commit message following as plain text.
Base commit at first detection — the hash is now a markdown link to IfcOpenShell/IfcOpenShell/commit/<hash>, with a fallback to plain text if the value is unknown.
Sort order — the following four report sections now sort by updated_at descending (most recently updated PR first):
Successfully Merged PRs
Failed to Merge PRs
Skipped PRs (covers both DRAFT and conflict-with-other-PRs categories)
@falken10vdl I was trying to figure out a way to resolve PR #7003 so it merged with BonsaiPR, and AI suggested the following approach. https://github.com/falken10vdl/bonsaiPR/pull/5
This is pushing beyond my bounds of understanding if this is a good approach or not. Defer to you, if you think it is.
@theoryshaw yes. That is correct as the build is done locally in a VM running at home. Let me update the script to pull also bonsaipr changes themselves so this is automated.
Thanks!
Comments
The script 00_clone_merge_and_create_branch.py is now updated and I have run the whole chain so a new release has been created:
Unfortunately (well fortunately... :) ) there are no Skipped (conflicts with other PRs). Eventually we will see PRs moving out of the draft status but still skipped due to conflict with others but not with the base. So Failed only gives a warning that the PR needs actually to be rebased.
Thanks!
Hi @falken10vdl,
Would it be possible to push the current list to the bonsaiPR repo? That way, peeps can do a pull request to either add, or remove from list.
EXCLUDED=comma_separated_list_of_pr_numbers_to_exclude...
Also, is there a way to automatically create a release every time there's either a new or modified PR? Or are you still manually triggering the build, and this would be too much overhead?
I'm not sure if the information is there and I just can't see it, but would it be possible to have the last commit hash of the source repository in the release page somewhere. Not really important as I can figure it out by comparing the data of the release and the dates of the commits in the source repo - just a "nice to have".
Changed. Only 5452 is excluded as it breaks execution. The ones excluded appear in the failed list:
I have a cron running on sundays and sometimes I trigger manually if I have made some change and want to propagate it.
Let me find out if I can get this done whenever there is a a new/modified PR.
Cheers!
@sjb007 Indeed! Thanks for the feedback! I have added a link after the title to the last commit of the base ifcopenshell before merging the PRs.
Thanks!
@theoryshaw
I have now a script that runs hourly and checks for changes in PRs If there is a change a new release is created. Note that I have added the hour-minute after the date info.
Cheers!
That is awesome!
Is it possible to automate pushing the branch to your fork as well?
https://github.com/falken10vdl/IfcOpenShell
@theoryshaw When the release is created, first the 00_clone_merge_and_create_branch.py script creates the branch. Ex:
Let me add a link to this branch in the release page after the link to the base branch commit.
Thanks!
nice!
Cheers!
nice add!
I have implemented automated updates in blender for BonsaiPR in the same way it is done for bonsai unstable repo. That way no need to keep downloading manually zip files and remove old ones with new ones.
You have the instructions in the README of https://github.com/falken10vdl/bonsaiPR:
I think this will allow for easier switching between both.
Cheers!
Since some time there are PRs that are skipped due to "Conflict with other PRs. Merges cleany with base", I have implemented a second pass. If there are any of those PRs, a new release is created going form newest to oldest PR.
This allows to have also an addon with the latest PRs with more probability to be succesfully merged.
You can see it by looking to the order in which the PRs were merged.
Hopefully this allows for testing the newest PRs regardless of the older ones.
Ex:
https://github.com/falken10vdl/bonsaiPR/releases/tag/v0.8.5-alpha2601172116
Triggered the creation of a new release in reverse order for which now those PRs are successfully merged and older ones not:
https://github.com/falken10vdl/bonsaiPR/releases/tag/v0.8.5-alpha2601172130
Cheers!
I would be nice if we could log the date and perhaps the commit that broke a pending PR.
Would think this would help the contributors to try and reconcile their corresponding commits.
What do you guys think about adding a new section(s) to this page: https://docs.bonsaibim.org/guides/development/installation.html about forks, so that there is a little explanation and more exposure about how to install BonsaiPR (and also highlight other "fork" branches like Saikei and 4DBonsai).
Let me dig a little bit. Si some repor on the merging conflict details, right?
cheers!
Let me dig a little bit. So some report on the merging conflict details, right?
cherry!
Yes, some log which help the contributors to coordinate their conflicting work--a 'conflict ping'.
Added a blurb about BonsaiPR (bleeding edge) installation:
https://github.com/IfcOpenShell/IfcOpenShell/pull/7721
Hi @falken10vdl , perhaps you did this already, but would it be possible to expose the .env EXCLUDED list somewhere on the BonsaiPR repo?
I'd like to remove https://github.com/IfcOpenShell/IfcOpenShell/pull/5452 because I think @chiragsingh1711 fixed it.
Sorry I missed this post. It is done!
Sorry I only xposed a .env example as I have the github token info in the local clone that builds the bonsaiPR addons (I do not use actions to build them, just make locally and then upload).
Cheers!
Added some info that hopefully it can point to where to fix the failed PRs:
Cheers!
Nice! that's cool!
I think there was something between..
BonsaiPR v0.8.5-alpha260310-ed52628 Pre-release
and
BonsaiPR v0.8.5-alpha260310-8bbeefa Pre-release
..that prevented BPR from enabling.
The difference seems just to be the inclusion of https://github.com/IfcOpenShell/IfcOpenShell/pull/5452
It looks an import was missing in the PR. I added it. Now it loads properly.
Check https://github.com/falken10vdl/bonsaiPR/releases/tag/v0.8.5-alpha2603111000
or newer
Cheers!
Could this 'conflict analysis' also be applyed to ...
Skipped - Conflict with other PRs. as well?
Would think it would help @Dimitris understand why his PR #7342 is not being merged into BonsaiPR.
hi @falken10vdl,
Pushed the following PR: https://github.com/falken10vdl/bonsaiPR/pull/4
Did not test, as i'm not sure how.
AI driven.
Conflicting files — each file path is now a markdown link to the file on GitHub at
IfcOpenShell/IfcOpenShell/blob/v0.8.0/<path>.Possible breaking commits — the short commit hash is now a markdown link to
IfcOpenShell/IfcOpenShell/commit/<hash>, with the commit message following as plain text.Base commit at first detection — the hash is now a markdown link to
IfcOpenShell/IfcOpenShell/commit/<hash>, with a fallback to plain text if the value isunknown.Sort order — the following four report sections now sort by
updated_atdescending (most recently updated PR first):@falken10vdl I was trying to figure out a way to resolve PR #7003 so it merged with BonsaiPR, and AI suggested the following approach.
https://github.com/falken10vdl/bonsaiPR/pull/5
This is pushing beyond my bounds of understanding if this is a good approach or not. Defer to you, if you think it is.
Hi @falken10vdl I pushed a couple changes. Do you have to manually pull these down, for them to take effect?
Cheers, Ryan
@theoryshaw yes. That is correct as the build is done locally in a VM running at home. Let me update the script to pull also bonsaipr changes themselves so this is automated.
Thanks!