digger
digger copied to clipboard
Non-blocking plan
Thanks for the talk at London DevOps Two idea's
- For longer running PR's it would be useful to have a 'draft' plan, similar to how you can be draft PR's. The idea being that plans can run so people can get feedback, but they don't lock and cannot be taken forward without going through the complete process.
- Delta plans. Similar, or an extension to the above where
-target
is in effect to see only desired changes
Thanks for filing the issue - both great ideas!
Re 1. thinking it could be "draft mode" corresponding to actual draft PR's; so if the user creates a draft PR then it's not locking and the comment posted by Digger indicates that it's a draft plan. Then it cannot be applied (Digger will comment an error) until the status of the PR is changed to "ready for review". At this point, a lock is acquired as normal. So essentially it is a bit "draft status" sync between Github PR status and Digger lock status. Is this roughly what you were thinking @timothyclarke ?
Re 2. Seems like could be addressed by introducing support of the target option for the plan command. So you'd comment digger plan -t <target>
and that'll run a targeted plan. Or maybe something similar to what tftarget does, sort of a "persistent target" for the entire pr; then it'll be smth like digger target <target>
comment that will set the target. The latter approach would introduce an extra stateful piece though in addition to locks. @timothyclarke I'm not sure that I'm getting your idea right though
Also tagging @motatoes - looking like 2 features shaping up
@ZIJ Both look correct. An extension for point 1 would be digger draft-plan
or similar
Seems simiar to "dry run / readonly mode" suggested by @jdziat - so tagging instead of creating a duplicate issue
Tracking the "Delta plans" idea separately in #240
This would be a great feature. We were using atlantis and now switched to digger and we really miss --target option which we had with atlatnis. For example, this would only plan and later apply a single module in our stack, rather than all 100 modules we are using in our stack: atlantis plan -- -target=module.our-custom-module.random_password.first_random_pass
Hey @danijelmarsic2 thanks for bumping up this issue for setting -target option. I have a question regarding atlantis do you pass the same flag when performing plan
and apply
as well? Or does the plan config propagate to the apply automatically after you pass the -target
flag during the plan stage?
Hey @danijelmarsic2 thanks for bumping up this issue for setting -target option. I have a question regarding atlantis do you pass the same flag when performing
plan
andapply
as well? Or does the plan config propagate to the apply automatically after you pass the-target
flag during the plan stage?
You can just run atlantis apply because atlatnis will automatically apply only the changes made by the previous plan. For digger any solution allowing --target option would be beneficial.