Add support for st2-packages branching (master) #2569
Conversation
- Autodetect st2-packages branch automatically - Make sure to suppress `git checkout` error code to avoid race, when remote `st2-packages` branch wasn't yet created - Fall-back to `st2-packages` master if there is no `vX.Y` branch in packages
| - | | ||
| git clone --depth 1 ${ST2_PACKAGES_REPO} /home/ubuntu/st2/st2-packages | ||
| cd /home/ubuntu/st2/st2-packages | ||
| git checkout ${CIRCLE_BRANCH} || true |
There was a problem hiding this comment.
Here we suppress git checkout error code to avoid race, when remote st2-packages branch wasn't created yet.
So it works as a fall-back to default master branch if there is no vX.Y branch in packages.
There was a problem hiding this comment.
I thought of that, but what bothers me is that we're implicitly treating master as default. There's a whole set of situations when mistake may cost us putting broken package to the repo. As I see it, if we don't have a sister branch, we fail, loud.
There was a problem hiding this comment.
Yeah, but it's circular dependency:
- You can't build packages in
st2repo before you create branch inst2-packagesrepo - You can't build packages in
st2-packagesrepo before you create branch inst2repo
So master is a fallback here.
As I know current release machinery works this way:
- Create
vX.Ybranch inst2repo - Create
vX.Ybranch in dependent repos likest2web(st2-packagesto add)
With this order checkout branch which wasn't yet created in st2-packages repo will raise an error in Circle.
^^ @manasdk is this order correct or no? (to make sure we have correct picture and if needed - I'll adjust the logic here).
There was a problem hiding this comment.
Well, yes, it is a circular dependency and yes, there's no way to resolve it without failing or falling back to master. My point is that it's better to fail because failing has no side effects.
There was a problem hiding this comment.
I'm still hoping someday we would just merge st2 and st2-packages and forget about this problem once and for all.
There was a problem hiding this comment.
^^
Yeah, initially, we couldn't think seriously about such option at all, because we couldn't touch entire existing st2 codebase and release machinery with our st2-packages changes.
So we kept that package logic isolated in new repo to avoid overflowing other team members (especially considering we had a lot of experiments and pretty big code flow).
When st2-packages matures and stabilizes, it's good to consider pros/cons again for keeping everything in one or separated repos 👍
Add support for st2-packages branching (master)
What this change brings
masterofst2repo will generate packages based onmasterofst2-packagesv1.3ofst2repo will generate packages based onv1.3ofst2-packagesv1.3branch inst2-packagesrepo, thenmasterwill be used as a fallbackst2-packagesrepo (st2branch was created, butst2-packagesbranch wasn't created yet)From this point
st2andst2-packagesrepos should have the same branchesvX.Y.cc @manasdk to include automated branch creation in
st2-packagesrepo as part of release machinery (same as you do forst2web).