Encourage the use of root_path in production to ensure single deployment

[lennartkats-db]

Changes

This updates mode: production to allow root_path to indicate uniqueness. Historically, we required run_as for this, which isn't actually very effective for that purpose. run_as also had the problem that it doesn't work for pipelines.

This is a cherry-pick from #1387

[pietern]

So this is breaking IFF:

1. You're a regular user
2. You don't have run_as set (i.e. it runs as self)

?

[lennartkats-db]

We previously showed an error under those conditions ('run_as' must be set). We now show an error about root_path.

[pietern]

Do you think we should continue to comment setting run_as, even if root_path is configured?

If a user goes in and looks at defaults and configures it to ~/some/path, it'll still have multiple deployments if multiple people deploy it, even though the warning is silenced.

[lennartkats-db]

I do think it's a good practice to set run_as despite its limitations and it seems okay to set it in the templates. Providing a warning when you only set run_as and don't set root_path seems like a sweet spot to me. Providing an error would be a breaking change and doesn't really seem warranted.

[pietern]

Do you think we should de-emphasize run_as in general?

[lennartkats-db]

run_as still seems helpful to me and it will become much more usable once we add support for it in pipelines.

[pietern]

Do you think we should continue to comment setting run_as, even if root_path is configured?

If a user goes in and looks at defaults and configures it to ~/some/path, it'll still have multiple deployments if multiple people deploy it, even though the warning is silenced.

[pietern]

Instead of keeping these around here, could you break out a field on the bundle struct where we can keep a snapshot of the selected target? Then you can interrogate it and there's no risk of other mutators changing it after selection. The targets in the configuration have no significance beyond this point.

E.g.

// Target stores a snapshot of the target configuration when it was selected.
Target *config.Target

[lennartkats-db]

Isn't it cleaner to just remove the side effect from select_target? Instead of just recording which target is selected, the mutator removes fields, which is a bit hard to discover and not really motivated in the code. It's a bit surprising if you want to build a new mutator that consumes this value. Based on your comments, the motivation is to clean things up in order for consumption by summary/validate; shouldn't we just make that a separate step?

[pietern]

What I see as a risk is that keeping them around means another location that new mutators can go and look at, even though everything under targets no longer has any effect. Variable interpolation won't run either, so values under it shouldn't be used.

I see how this is most convenient though. @andrewnester What do you think?

[lennartkats-db]

It's just that over the past year I ran into this problem twice. You need to use a step through debugger to find where this property is secretly deleted. And the code that deletes it includes no rationale and is just meant to select the default target.

[lennartkats-db]

Alright, I don't want to leave this PR open just because we can't make a decision here. I added 6ea5306 which merges the cleanup behavior back into SelectTarget and adds a few comments about the behavior for maintainers.