-
-
Notifications
You must be signed in to change notification settings - Fork 44
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
Support triggers between workspaces #1212
Comments
I believe this is very related to the state consumption by remote workspaces (which I believe it's not implemented here, because there's no way to allow consumption from certain workspaces). Since a workspace can be a consumer of another one, any change in the consumed workspace should trigger a run in the consumer workspace. This is already implemented in TFC, and it's very useful |
Hello @juan-vg state consumption from one workspace to the other is supported, you could check here |
Hello @alfespa17! While I agree it's possible, what I mean is that the way of doing so is limited compared to TFC (AFAIK). I mean, TFC allows to specify which workspaces are allowed to consume, so not necessarily all of them are allowed. However, the main topic of my previous message was about triggers and how useful they are when talking about scenarios where consumers are broadly used. |
Feature description 💡
It would be great if it was possible to trigger a plan / plan&apply / plan & approve & apply etc in another workspace.
We would be able to get rid of our CI system for the ordered deployment of a change between the dev account (workspace), staging, and prod.
( it might be possible to do this now, but using VCS for the dev, and then api calls for staging and prod.)
Anything else?
In the future, we're expecting stacks from hashiconf, to vaguely group multiple workspaces of the same module, for different envs or regions. This can be a starting block for connecting workspaces.
The text was updated successfully, but these errors were encountered: