Eugen
Eugen
Yeah, It's about Pros/Cons tradeoff as usual. While the improved level of automation, there's already high amount of indirection and moving pieces in the packaging process. Trying to dynamically pull/install...
> (e.g. this step is called before password is written to the config or similar) Yes, because `st2ctl reload` is bundled in packaging `postinst` and executed before we can edit...
This also may hang entire `apt/yum install st2` installation in next versions (`v2.3+`) since we return correct exit code if register content failed https://github.com/StackStorm/st2/blob/a826898e52dcda848fcfbe5b0ae1a719d08ca288/st2common/bin/st2ctl#L226-L227
I'm 👎 for any uninstallers since there is a big danger in removing packages or altering configurations user might need for other software in a system. - Add here complexity...
That's totally OK. - You can build and deploy packages only for specific distros: ex `el6` and `trusty` for example what will increase revision only for those 2 distros. Another...
^^ @enykeev @dennybaa @lakshmi-kannan please review the logic and provide your ideas if you have. That'll be better automated after merging: ~~https://github.com/StackStorm/st2-packages/pull/227~~ ~~https://github.com/StackStorm/st2-packages/pull/229~~ https://github.com/StackStorm/st2/pull/2569 https://github.com/StackStorm/st2/pull/2570
@enykeev see: https://github.com/StackStorm/st2-packages/pull/227 PR.
As discussed with @enykeev, closing #227 branch autodetection as error-prone way. `ST2_GITREV` hardcoding in each branch of `st2-packages` will work. I guess we'll end up with hardcoding in `st2` repo...
That's what I thought about when implemented existing revision number logic. I wanted to rely on external service like Redis with locking and releasing to avoid any possible race conditions...
Happened for the first time now with @Kami during the year or something :+1: https://circleci.com/gh/StackStorm/st2/4522 If there is less than 10mins between merging 2 PRs into master, - they'll race...