feature request: add option to discard plan or support multiple independent plans

[cludden]

in addition to or instead of #117 . would like to support various PR flows that are currently difficult with the existing implementation, mostly around validation and/or plans that don't persist or overwrite other plans

[ljfranklin]

@cludden could you give a few more details about your PR workflow? Do you have a single environment with multiple PRs submitted against it?

[cludden]

@ljfranklin a common flow for us is to validate infra changes at PR time, and we'd like for these plans to not interfere with actual infra deployments, today we do this as a task, but there is a lot of overlap with this resource. quick example: if one engineer is iterating on larger infra changes, we don't want these plans applied the next time the resource is run, and my understanding of the current implementation is that they're can only be a single plan per workspace at any given moment

an alternative to a discard_plan option, would be the ability to assign a unique id to a plan, and specify that in the apply step.. im open to other ideas as well, I'm also happy to submit a PR if any of these suggestions sound reasonable to you

[ljfranklin]

current implementation is that they're can only be a single plan per workspace at any given moment

That is correct. The current plan implementation creates a new temporary workspace named $ORIGINAL_ENV-plan to hold the contents of the plan file. The original idea with using a fixed name instead of a random name is to avoid leaking plan files if a plan was created but never applied.

add option to discard plan

This makes me a little nervous long-term. The Concourse team has put out multiple proposals to refine the resource interface. Last I checked this proposal would require that check can retrieve metadata for a version produced by put. If there's no persisted planfile I don't see how the resource could satisfy that requirement in that flow.

would be the ability to assign a unique id to a plan

This sounds reasonable but we'd have to be careful about implementing it. The two main issues are deleting the unused planfiles and not breaking people on upgrade. I think the following implementation would work:

• On plan put:
  • Create a plan workspace named $ORIGINAL_ENV-plan$UUID
  • Store plan_id field in version struct
• On apply put:
  • if version contains plan_id, download $ORIGINAL_ENV-plan$UUID planfile
  • else download $ORIGINAL_ENV-plan
  • on success, delete all plan workspaces for that env
    • run terraform workspace list and use regex to look for -plan$UUID suffix

This implementation is a little more involved but does have the benefit of requiring no new pipeline config options and doesn't leak planfiles. Open to suggestions if you see a better solution. I'll mark this as open for a PR, appreciate the contribution if you have the time!