Make editor pinning optional [skip ci]

[kivistikliis]

---

Purpose of this PR

Makes editor pinning optional, makes shared metafile a bigger 'source-of-truth' for editors, and allows more flexibility on setting up editors:

• Editor section in shared metafiles now includes booleans for if to run Nightly or ABV on PRs for a given editor (instead of scattered in other metafiles or python)
• For each editor, we can specify if to use editor pinning or not. If we choose not to, we use editor priming as before. If none of the editors uses editor pinning, then no editor pinning jobs are created.
• If we choose to not use editor pinning, we can also specify if we want this editor configuration to use --fast or not. If we want, we can also set up both options and name them as we wish

This makes it possible to not run editor pinning for every track on a branch, or bring in the old latest and --fast options, or disable it as we branch off master, and allows to keep the python script consistent across all branches (should ease backporting things which now differ due to editor pinning being present or not)

This is done by each editor section containing (examples copied from updated docs):

  - track: 2020.2 # run against track 2020.2
    name: fast-2020.2  # use this name to refer to the editor configuration (in job ids etc)
    rerun_strategy: on-new-revision
    editor_pinning: False  # don't use editor pinning, let it use editor-priming instead
    fast: True  #use --fast flag (so get the latest built revision)
    abv_pr: True  #trigger ABV on PRs (so run fast-2020.2 like before editor pinning)
    nightly: False  #don't run nightly on this editor

  - track: 2020.2 # run against track 2020.2
    name: 2020.2 # keep the name the same
    rerun_strategy: on-new-revision
    editor_pinning: True  # use editor pinning
    nightly: True  # run nightly
    abv_pr: False # dont trigger ABV on this editor on PRs

---

Testing status

• Set up for 8xx, see links below
• ran different editor setup pipelines (cancelled them, but pipelines themselves are what is expected)

---

Comments to reviewers

See more details in the updated docs, or check out some examples on this branch branch https://github.com/Unity-Technologies/Graphics/tree/yamato/editor-pin-boolean-examples/.yamato

Also took the changes on 8xx branch, to show that we can now keep same python across branches (with or without editor pinning) https://github.com/Unity-Technologies/Graphics/tree/8.x.x/yamato/test-editor-pin (compare 8.x.x/release...8.x.x/yamato/test-editor-pin )

The changes to custom-revision test-dependencies job seem to be legitimate (when compared to 9.x.x branch), and have been possibly missed before

One of the examples: https://yamato.cds.internal.unity3d.com/jobs/902-Graphics/tree/yamato%252Feditor-pin-boolean-examples/.yamato%252F_abv.yml%2523all_project_ci_latest-2020.2

When changes taken to 8xx branch https://yamato.cds.internal.unity3d.com/jobs/902-Graphics/tree/8.x.x%252Fyamato%252Ftest-editor-pin/.yamato%252F_abv.yml%2523all_project_ci_fast-2020.1/3720199/job

[theopnv]

On other branches it indeed is using the source file argument, but I admit I don't understand why. Aren't we supposed to use the $CUSTOM_REVISION variable?

[kivistikliis]

I think this gets passed to the editor-priming job, which uses the $CUSTOM_REVISION and then outputs the unity_revision.txt, and we want to use what the editor priming outputs.
Although, now I am thinking if this even matters because in both cases the revision should be the same anyways?

[sophiaaar]

yeah Liis is correct, the next line down is green and - unity-downloader-cli --source-file unity_revision.txt -c editor --wait --published-only

[theopnv]

Ah yes, sorry, I forgot how the "old" editor priming works :) 100% makes sense, thanks!