incoherent behaviour when using API variables

Opis

Część naszych templejtów wystawia API w postaci listy zmiennych do zdefiniowania z jakąś domyślną wartością. Przykładowo .containers i zmienna CONTAINER. Zmienna ta - wg opisu w readme - pozwala wyspecyfikować nazwę kontenera wraz z tagiem, a w przypadku niezdefiniowania nazwą jest nazwa projektu a tagiem jest nazwa brancha (upraszczając).

Nie jest to jednak prawda. Brakuje informacji, że aby zadziałało to tak, jak w opisie, konieczne jest nadpisanie tej zmiennej w KONKRETNYM jobie - w tym wypadku w jobie template-container-build i w jobie template-container-build-master.

Natomiast na zdefiniowanie takiej zmiennej nadaje się kilka miejsc - np. mógłbym to zdefiniować rozszerzając definicję joba .template-container-build-base, albo definiując swojego joba i zmodyfikować opcję extends w jobach template-container-build*. Obie te drogi nie zadziałają, ponieważ ostatnie miejsca definicji wartości tej zmiennej nadpiszą te wcześniej zdefiniowane.

Jak to rozwiązać

Proponuję do wszystkich zmiennych z wartością domyślną dodać zmienne pomocnicze z wartością domyślną, a do wartości zmiennych opisanych w API odnosić się warunkowo.

Przykład dla zmiennej CONTAINER - zamiast definiować wartość domyślną CONTAINER: "cokolwiek" zdefiniować zmienną _TEMPLATE_CONTAINER_DEFAULT_NAME: "cokolwiek". Przy odwołaniu do zmiennej CONTAINER, która może nie być zdefiniowana, odwoływać się przez ${CONTAINER:-${_TEMPLATE_CONTAINER_DEFAULT_NAME}}

Co trzeba ustalić / sprawdzić

1. czy nadajemy jakiś prefix dla naszych zmiennych "wewnętrznych" - tak, proponuję _TEMPLATE_
2. Co gdy zmienna z API jest używana więcej niż raz?
   1. Możemy zdefiniować jakąś zmienną _TEMPLATE_CONTAINER_FINAL: "${CONTAINER:-${_TEMPLATE_CONTAINER_DEFAULT_NAME}} w sekcji variables, ale tutaj znowu może się okazać, że miejsce definicji nie będzie jeszcze zawierać definicji zmiennej CONTAINER dostarczonej przez użytkownika.
   2. możemy taką zmienną zdefiniować w before_script: zagrożenie, że user nadpisze before_script
   3. możemy tą zmienną zdefiniować w pierwszej linii script: co jeśli zmienna będzie użyta w before_script
   4. możemy olać ten temat i po prostu wszędzie odwoływać się warunkowo (w tej chwili byłoby to dwukrotne odwołanie do zmiennej CONTAINER) - jestem za tym rozwiązaniem
3. Czy warunkowość zadziała w innych miejscach, np. w polu image - do sprawdzenia
4. Czy opisujemy ten sposób w readme tak, by jak ktoś będzie chciał jednak skorzystać z naszych domyślnych wartości na swój sposób - imo nie, to już zbyt zaawansowane użycie

Gdzie trzeba zmienić

• .containers
  • DOCKERFILE_PATH
  • CONTAINER
• .shellcheck
  • SHELLCHECK_VERSION - tutaj do sprawdzenia kwestia warunkowości w image
  • SHELL_SCRIPT_PATHS - tu chyba podobny mechanizm jest zastosowany, choć tutaj zmienna z domyślną wartością jest zdefiniowana w pierwszej linii script.