Skip to content

Add support for st2-packages branching (master) #2569

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
arm4b merged 1 commit into from
Mar 11, 2016
Merged

Add support for st2-packages branching (master) #2569

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 4 additions & 2 deletions circle.yml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -21,7 +21,6 @@ machine:
DISTROS: "wheezy jessie trusty el6 el7"
NOTESTS: "el7"
ST2_PACKAGES_REPO: https://github.com/StackStorm/st2-packages
ST2_PACKAGES_BRANCH: master
ST2_DOCKERFILES_REPO: https://github.com/StackStorm/st2-dockerfiles
BUILD_DOCKER: 0
DEPLOY_DOCKER: 0
Expand All @@ -40,7 +39,10 @@ machine:

checkout:
post:
- git clone --depth 1 -b ${ST2_PACKAGES_BRANCH} ${ST2_PACKAGES_REPO} /home/ubuntu/st2/st2-packages
- |
git clone --depth 1 ${ST2_PACKAGES_REPO} /home/ubuntu/st2/st2-packages
cd /home/ubuntu/st2/st2-packages
git checkout ${CIRCLE_BRANCH} || true
Copy link
Member Author

@arm4b arm4b Mar 9, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

@enykeev enykeev Mar 9, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member Author

@arm4b arm4b Mar 9, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, but it's circular dependency:

  • You can't build packages in st2 repo before you create branch in st2-packages repo
  • You can't build packages in st2-packages repo before you create branch in st2 repo

So master is a fallback here.

As I know current release machinery works this way:

  • Create vX.Y branch in st2 repo
  • Create vX.Y branch in dependent repos like st2web (st2-packages to 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).

Copy link
Member

@enykeev enykeev Mar 9, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

@enykeev enykeev Mar 9, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm still hoping someday we would just merge st2 and st2-packages and forget about this problem once and for all.

Copy link
Member Author

@arm4b arm4b Mar 9, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

^^
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 👍

- .circle/buildenv.sh

dependencies:
Expand Down