You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In order to enable projects to use the IDs from the outputs command in their Rojo bundles before deploying, we could split out place deployments into a separate command. The workflow would then look something like:
# Create the project's resources
mantle prepare
# Save the outputs in a JSON file
mantle outputs -o src/resources.json
# Build the Rojo project into a place file, including the outputs JSON file
rojo build -o game.rbxlx
# Deploy the place file
mantle deploy
What does this mean in terms of implementation? Do we create two resource graphs in each environment – one for prepare and one for deploy – and have the deploy graph depend on the deploy graph? This would be the second use case for having multiple graphs which can depend upon each other (see #63) so it seems like it would be a good idea to refactor this the resource graphs to support this.
I want to make sure I properly understand what is different between the prepare and deploy stages sufficiently here. Are there other operations that should be moved from prepare to deploy?
Also, does this affect the configuration format? Should deploy-related objects be defined separately from the prepare-related objects?
I titled this issue with "consider" because I'm still torn on this, but atm it seems like the right path forward.
The text was updated successfully, but these errors were encountered:
Thinking more about this and I realized a more conceptual understanding of this is to split up creation of resources with updates of resources. One complication with this is resources which are re-created when updated. We may need to make this a known concept for the reconciler so that it can correctly split tasks between phases.
Also: reference the Azure DevOps CLI for example of how we could structure this. IIRC, there are separate phases like "init", "provision", and "deploy". Each phase has its own command, or you can simply run the "up" command to run all three. "init" isn't really applicable for us, but the others are.
In order to enable projects to use the IDs from the outputs command in their Rojo bundles before deploying, we could split out place deployments into a separate command. The workflow would then look something like:
What does this mean in terms of implementation? Do we create two resource graphs in each environment – one for prepare and one for deploy – and have the deploy graph depend on the deploy graph? This would be the second use case for having multiple graphs which can depend upon each other (see #63) so it seems like it would be a good idea to refactor this the resource graphs to support this.
I want to make sure I properly understand what is different between the prepare and deploy stages sufficiently here. Are there other operations that should be moved from prepare to deploy?
Also, does this affect the configuration format? Should deploy-related objects be defined separately from the prepare-related objects?
I titled this issue with "consider" because I'm still torn on this, but atm it seems like the right path forward.
The text was updated successfully, but these errors were encountered: