Building Block definition and working with branches ("stuck BB definition")
Jörg Gottschlich
It's tricky to work with the "Git Reference" field in BB definition because it might lead to "dead ends" until you update the Git Reference.
- You extend a BB repo in a feature branch (e.g. feat/extend-building-block)
- You create a BB definition with a "Git Reference" to that feature branch.
- After testing everything etc. you merge the feature branch into the main branch
- However, the BB definition will continue to execute the old branch (as designed). No matter what you change in the main branch (after the merge) it will not be picked up by the BB definition until you remember to update the Git Reference. This way, you can set a trap for yourself.
When you delete the old feature branch, the BB definition at least fails and you will notice (though maybe with user exposure).
Can meshStack support the BB designer somehow to be more conscious about which branch they select? I can imagine that his happens quite often as best practice is to work in feature branches. Also for demo settings it might be a trap to fall into (when you set something up quickly to adjust it later).
TL;DR:
BB definitions stuck to a git branch work as designed, but might lead to a trap when merging branches as you need to remember to update the "Git Reference" of all affected BB definitions accordingly.
Andreas Grub
One could display a warning when a Git reference is not matching
/^(main|master|v?\d+\.\d+\.\d+|[a-f0-9]{8,64})$
in the panel and inform/warn that you have pinned to a floating/ephemeral branch? Also, even using
main
/master
is not something one should really do, but always pin to a commit hash or (assumed to be immutable) semantic-versioned tag IMHO.One could become a bit stricter and not allow releasing a building block definition from draft state unless the Git reference is either a commit hash or a semantic-versioned tag?