Should Project is_version_controlled be read only?

[ArturDorochowicz]

Describe the bug The is_version_controlled argument of a project is settable, but it doesn't seem to do much. Should it be read only?

If I provide, for instance, a git_library_persistence_settings block in a project resource, the project will be created successfully with VCS support, no matter what value the is_version_controlled argument has (i.e. also when it is set to false).

Also, for an existing project configured with VCS support (created initially with is_version_controlled = true), I can change is_version_controlled to false and apply successfully. The project doesn't change to no VCS support. Not that I'd expect it, I'm just pointing out the fact that the argument doesn't appear to do anything.

Steps to reproduce

1. Go to '...'
2. Click on '....'
3. Scroll down to '....'
4. See error

Expected behavior A clear and concise description of what you expected to happen.

Logs and other supporting information Add the output of running tf plan or tf apply along with any errors in the Octopus Server logs.

Screenshots If applicable, add screenshots to help explain your problem.

Environment and versions:

• OS: Windows
• Octopus Server Version: 2022.4.8474
• Terraform Version: 1.3.9
• Octopus Terraform Provider Version: 0.10.5

Additional context Add any other context about the problem here.

[mjhilton]

I can see how this feels a bit redundant.

I think I'd prefer to keep the flag as editable so that it's a very explicit action to migrate to a config-as-code project, given that's a one-way door. However, I think the current implementation could be a bit nicer - with some proper error messages for expecting/requiring the git persistence settings to be available if the version controlled flag is set to true.

I'll leave this open for us to potentially add some nicer messaging into the provider logging.