[v2 refactoring proposal] Decouple the runner creation from v1 schema

[yuwenma]

Related: #5673

Fixes #5797

Description
In runner creation, the schema is no longer bundled with v1 schema (latestV1.skaffoldConfig) but used the interface util.VersionedConfig.

All v1 commands are manually tested to make sure this PR does not break existing commands.

Follow-up Work (remove if N/A)
Distinguish v1 and v2 schema based on the in-use apiVersion in skaffold.yaml.

[codecov]

Codecov Report

Merging #6068 (57d478f) into master (0b13fa0) will decrease coverage by 0.62%.
The diff coverage is 47.82%.

@@            Coverage Diff             @@
##           master    #6068      +/-   ##
==========================================
- Coverage   69.92%   69.29%   -0.63%     
==========================================
  Files         481      482       +1     
  Lines       18342    18526     +184     
==========================================
+ Hits        12825    12838      +13     
- Misses       4562     4734     +172     
+ Partials      955      954       -1     

Impacted Files	Coverage Δ
cmd/skaffold/app/cmd/apply.go	25.00% <0.00%> (ø)
cmd/skaffold/app/cmd/delete.go	57.14% <0.00%> (ø)
cmd/skaffold/app/cmd/deploy.go	56.52% <0.00%> (ø)
cmd/skaffold/app/cmd/filter.go	25.58% <0.00%> (ø)
cmd/skaffold/app/cmd/generate_pipeline.go	61.53% <0.00%> (ø)
cmd/skaffold/app/cmd/render.go	40.74% <0.00%> (ø)
cmd/skaffold/app/cmd/test.go	46.66% <0.00%> (ø)
pkg/skaffold/runner/v1/generate_pipeline.go	0.00% <0.00%> (ø)
pkg/skaffold/runner/v2/generate_pipeline.go	0.00% <ø> (ø)
cmd/skaffold/app/cmd/diagnose.go	62.50% <50.00%> (-2.02%)	⬇️
... and 24 more

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 0b13fa0...57d478f. Read the comment docs.

[yuwenma]

@nkubala gentle ping.

[yuwenma]

rebased and merge conflict resolved.

[nkubala]

I see a few TODO leftover in this PR, but I'm not sure they match up with the follow up work detailed in the description. if those aren't going to be addressed in this PR, can we leave a short note in the PR description for what needs to be done later?

I'm also feeling a bit strange about moving the type checking from the method signature into a simple typecast in the method - this seems brittle to me. as an example:

func targetArtifacts(opts config.SkaffoldOptions, configs []util.VersionedConfig) []*latestV1.Artifact {
	var targetArtifacts []*latestV1.Artifact
	for _, cfg := range configs {
		for _, artifact := range cfg.(*latestV1.SkaffoldConfig).Build.Artifacts {

it might be better to abstract this away into Get methods defined on the Pipeline, similar to what we do in the RunContext. or maybe this is just an intermediate step and this will disappear in the future 🤷

[nkubala]

should this be addressed in this PR?

[yuwenma]

Maybe not, providing a v2 validation is not a small change and may deserve another PR.

[yuwenma]

I see a few TODO leftover in this PR, but I'm not sure they match up with the follow up work detailed in the description. if those aren't going to be addressed in this PR, can we leave a short note in the PR description for what needs to be done later?

The TODOs are to save some code reading effort for future work, like marks. It's not necessary though. Removed. The detail is in this doc. Per offline discussion, I'll leave it to you to determine how the refactoring should work and I'm only going to focus on the branch v2.

I'm also feeling a bit strange about moving the type checking from the method signature into a simple typecast in the method - this seems brittle to me. as an example:

func targetArtifacts(opts config.SkaffoldOptions, configs []util.VersionedConfig) []*latestV1.Artifact {
	var targetArtifacts []*latestV1.Artifact
	for _, cfg := range configs {
		for _, artifact := range cfg.(*latestV1.SkaffoldConfig).Build.Artifacts {

it might be better to abstract this away into Get methods defined on the Pipeline, similar to what we do in the RunContext. or maybe this is just an intermediate step and this will disappear in the future 🤷

The interface is my refactoring proposal, and this PR shows the implementation details how that could be done.

[MarlonGamez]

There is one small linter error but I think this is pretty much ready to merge after that

[google-cla]

All (the pull request submitter and all commit authors) CLAs are signed, but one or more commits were authored or co-authored by someone other than the pull request submitter.

We need to confirm that all authors are ok with their commits being contributed to this project. Please have them confirm that by leaving a comment that contains only @googlebot I consent. in this pull request.

Note to project maintainer: There may be cases where the author cannot leave a comment, or the comment is not properly detected as consent. In those cases, you can manually confirm consent of the commit author(s), and set the cla label to yes (if enabled on your project).

ℹ️ Googlers: Go here for more info.