So we have tried foundry branching to help manage our workshop, pipeline, and code. A few elements we’ve found confusing
Updating the workshop module and ontology objects can be confusing. Validating object explorer entries from submission via the Ontology screen is hard. We had to make a small workshop module to “see” if our submissions were correct.
We were unable to selectively merge ontology objects and it’s an all or nothing operation.
Creating and indexing actions on a specific branch is confusing. Trying to merge parts on a specific branch continues like number 2 above.
We found it difficult to trigger a rebase on the ontology itself and workshop especially when working with multiple branches (to solve #2 above). It seemed like things would go out of sync.
It wasn’t clear if the code repo is connected to a foundry branch or not. I personally recall at Devcon them being not connected? Maybe I’m mis remembering.
We think it’s a good feature, but unless we are going to touch something that is absolutely user facing it’s easier to just avoid it. Maybe that was the intention?
Thank you for trying out Foundry Branching and for this feedback!
A couple questions so we can action these notes:
Can you describe what specifically is confusing? It sounds to me that you are submitting actions in Workshop that create objects and you want to verify that the objects have been created? What would you expect the behavior to be once the objects are created? Right now, you can embed an Object Table or an Inline Action Table widget with a prefilled object set in your Workshop module to see any newly created objects come through.
To clarify, if you are referring to object instances, any object instances made on a branch will not merge to Main when you merge a foundry branching proposal. These object instances are meant to be for testing on the branch only. If you need the objects on Main, you should create them on Main. If you are referring to changes made on object types, we are soon going to release the ability to remove specific resources from your Foundry Branching proposal. This means you can remove any changes that you don’t want merged and merge the remaining.
How would you expect the behavior to look for indexing? We are exploring improvements with allowing some level of bulk-indexing here, so you don’t need to individually index each action type. Would that help?
Were the rebase buttons hard to find or was the rebase process confusing itself?
We recently introduced support for Code Repos (python transforms) and are actively working to introduce support for Typescript v1 functions. If the code repo shows up in the branching bar resources, then it is on your branch.
We appreciate your feedback and we’re working to continually make the branching process smoother.
The issue here is you don’t have a foundry branch view on the object explorer (or maybe we are too blind to see it haha). If you’re creating objects via a user submission, you must make a separate table in workshop to view them. Many times there are properties that are not going to be user facing. So you make a quick table in a random workshop module just to “see” what is the same thing as the Object Explorer. I did what you are describing, but to my other team members they didn’t understand it originally because they are used to viewing the Object Explorer.
I am referring to your latter point and so I’m glad you’re on that.
Yes that would help. However, my other points below are going to expand on it.
Let me expand this more below to unpack a few examples
I use typescript v1 primarily so this would be helpful.
The rebase did not appear despite the main module being updated on workshop. I saw in the documentation rebase should be there, and when I had ‘review changes’ between the main module and my foundry the changes were detected. No rebase was occurring. I wish I could have saved this as an example, but I ended up just deleting what was on my branch and remaking it. I tried submitting it as a bug as a support ticket, but I didn’t see ‘foundry branching’ on the platform to submit it.
On the #3 item above, I had updated my main branch with another branch for an ontology object. The secondary branch I had no ability to ‘rebase’ my ontology objects. Instead, I was stuck with the “old ontology properties” which was preventing me from further working in workshop.. who actually got the rebase and was expecting the branches ‘new properties.’ I was hoping for a ‘rebase’ on the ontology - but I had indexed the ontology object to the prior one. Below is a pic where I had an object type and changed properties to try and explain it better:
We are tracking supporting Object Explorer in Branching long term. This is good signal for us to have.
Regarding the rebase issues, the workshop one sounds like a bug and I’d encourage you to submit it as a Workshop support ticket (we’ll look into adding foundry branching as an option)
For the ontology, there actually is a rebase option.
You need to create a proposal on your branch and then navigate to the ontology proposal, at which point you’ll see this rebase button.
one confusion then with the proposal to trigger the ontology rebase is what if youre still working? in the prior example, I had a change I needed to “see” while developing. That means I have to get to the proposal step to trigger the ‘merge from main’ from the ontology?
Hey @chlor8 apologies for the delay. We are actually working on a new rebase-mode in OMA that would let you rebase with Main without creating a proposal (amongst many other improvements). It’s currently being tested and will rollout soon. For now, yes you’ll need to create a proposal but that doesn’t prevent you from continuing to dev and make changes on your branch! You can continue working on it with the proposal open.
