Suggestion: We could label the loop instead and use continue Loop. Continue/break have a simpler flow and are usually considered more idiomatic Go.

(Same with other loops.)

Are you thinking about this form:

next:
	for name, value := range pr.richParametersFile {
		for i, r := range resolved {
			if r.Name == name {
				resolved[i].Value = value
				continue next
			}
		}

		resolved = append(resolved, codersdk.WorkspaceBuildParameter{
			Name:  name,
			Value: value,
		})
	}

If so, then it will be a bit different logic - iterate over pr.richParametersFile again and again.

Alternatively, I can add break/if, but with goto the code is shorter/simpler.

I think there's a misunderstanding around how loop labels work. This is kind of like tagging a loop so that continue knows where to go. See here (only one iteration through the range is performed): https://go.dev/play/p/oAbzFLuh8O5

The reason I say continue/break [Label] is simpler, is that they don't break control flow, whereas goto does and can go anywhere in the function.

#9019

Why do we check len 0 here? Wouldn't it be possible for some build options to be provided but not this one? Should are check the contents instead?

This condition only applies to ephemeral/one-time build parameters, hence tvp.Ephemeral. !pr.promptBuildOptions means that the user didn't use the flag --build-options to input manually values for next build options, and len(pr.buildOptions) == 0 means that they didn't provide them via --build-option key=value.

I understand the reasoning for the other checks, however my thinking is that, say there are two ephemeral values. The user providers only one of them via --build-option. Then len(pr.buildOptions) == 1 even though current tvp wasn't provided. Does that make sense?

#9019