-
-
Notifications
You must be signed in to change notification settings - Fork 58
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.
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
Review build process for ldap and rbac #716
Comments
we have I'm including Orquesta in the list, because its version is bumped manually once in several months or before the st2 release, but not on every change which results in the same result. The fundamental solution to me looks like fully moving both https://github.com/StackStorm/st2-rbac-backend and https://github.com/StackStorm/st2-auth-ldap codebase into the This would really reduce the maintenance burden, rather than increase it. The downside might be losing some modularity? In a 3rd view, everything is about tradeoffs. Is it really a problem considering how frequently these repos change? For st2 master, on every next push or merge the rebuild would already happen by automatically picking up the latest code. And we do update st2 frequently. On release, the changes will be picked up in any way as automation creates a |
We are already publishing st2client wheels in the So, we should be able to do something similar with Of these 4, only I'm going to punt releasing these on pypi, or merging them into our st2 monorepo for a future release, not 3.7.0. |
ST2 packages are re-built on a merge on st2-packages or st2 repo.
But as ST2 just refers to master branch of st2-auth-ldap and st2-rbac-backend, then a new package won't be built on a merge to either of these repos.
The text was updated successfully, but these errors were encountered: