auth0-deploy-cli
auth0-deploy-cli copied to clipboard
auth0
Test mode (aka "dry run")
We may want to consider a feature where you can run import but in test mode, so no changes. This would be useful for when deploying to production.
It should be fairly easy to add --test param.
This would be very useful in CI!
With respect to the naming: --test is fine, however I think --dry-run would be more clear.
This is important for safe deployments - we'd like to do a dry-run of a deployment with no side effects, that logged what would be changed, then have a manual step to review before deploying the actual change.
I also want to chip in as we have multiple environments (different tenants) and it happens often that we have a misconfigured .json but only for staging or production, therefore it fails during our deployment step. With a --dry-run option, we could test all of our config before ever hitting our deployment pipeline.
Please make this happen! 🙏
--dry-run would be extremely helpful when moving from "unmanaged/by-hand configuration" to auth0-deploy-cli.
As someone who had to go through the process of trial and error, I'd really appreciate a test mode. 👍
Little update on the Auth0 side – we've identified this as a high-impact feature and have it prioritized fairly high on the roadmap. Compared to some of the other initiatives we're working on, this skews towards the larger side and it's something we want to get right, so we're taking our time. However, we do see ourselves working this fairly soon!
I'd also like to take a moment to plug Auth0's Terraform Provider which provides this as a first-class feature already. If you already support Terraform workflows, you may find it to be more suitable to your needs. Both tools with exist alongside each other well into the future.
It's great that Auth0 has a Terraform provider. However I'd rather wait for version 1.0 before starting to use it. Version 0.29.0 sounds to me like "not ready for production use" or "breaking changes coming soon".
--dry-run would be extremely helpful when moving from "unmanaged/by-hand configuration" to auth0-deploy-cli.
Exactly this! 🚀
Any update on this? It's been 5 months since it has moved to a "fairly high" priority 😅
Despite the seeming lack of progress, this has been getting pushed forward behind the scenes, albeit slowly. It was added to the roadmap not too long ago with work slotted for next quarter. Before then though, I'll draft up a proposal similar to #451 that outlines the suggested direction as well as soliciting general feedback. Until then, if folks have any initial thoughts and suggestions, this thread is still appropriate. Being able to consider this feedback upfront will hasten the process.
Unlike other features, this request has quite a few moving pieces and will fundamentally impact the mode of interaction, so I'd like to get it right. For example, do we integrate into the import function? Do we create a new dry-run command? Both? How do we express an approval flow? Further, I'm trying to be a bit careful to not introduce any breaking changes, but adding a dry-run check before import may be a sensible default. There are several details that need to be ironed out.
In terms of a delivery date, I think late 2022 - early 2023 is a reasonable expectation. I'm hoping to hit the earlier side of this range, but again, I'd like to get this right and make sure that it suits your needs.
@willvedd any updates on this :) Our Auth0 deployment logic is growing fast and not having "dry-run" functionality to verify our changes during CI is biting us hard.
Hey guys just keeping the convo alice here. The dry-run feature would make SO much sense :pray: Happy new year!
As an additional note I didn't see explicitly mentioned: having a way to use this as a test to ensure the active configuration of my tenant matches the input I provided would be super useful. For example, if the "dry run" produces a diff of what changes would have been made, being able to programmatically test if that diff is empty (or just returning a non-zero exit code if it's not?) would be a useful feature for detecting unmanaged configuration skew.
So glad to see this is being worked on!
