Template updating improvements

[gilzow]

Next steps to be taken in improvements to the template updating process. cc: @chadwcarlson

• Migrate current set of priority templates from using auto-updating workflows to use reusable workflows
  • Add reusable workflow based on @chadwcarlson 's POC to monitor changes to PSH config files and push those changes as a PR to this repository for the affected template
  • Replace the current workflows in this repo with the new reusable workflow versions
• For the Priority Templates, continue separating what is tracked in template-builder vs what is tracked in a template's repository
  • This refers to having template builder track only PSH configuration files for a template while all other parts are tracked in the template's repository
  • Look into the Remote Project issue that might be surfaced when this migration is complete.
• Add in the type of template (e.g. Starters, Demos, Experimental) into each template's .platform.template.yaml file
  • Discover which property in the above file should be used for this information
• Look into adding a new doit command that creates a new template adhering to this new methodology

[chadwcarlson]

Template reliability roadmap

1. Set up templates issue/PR GitHub Project

   • Template-builder board
   • "All templates" board (to start)
   • Auto-add repo issues to Org Project PoC

2. Finalize the auto-update (daily) and template-builder update (monthly?) workflow for Starters

   • Add reusable workflow based on @chadwcarlson 's POC to monitor changes to PSH config files and push those changes as a PR to this repository for the affected template
   • Migrate current set of priority templates from using auto-updating workflows to use reusable workflows
   • Replace the current workflows in this repo with the new reusable workflow versions
   • Add in the type of template (e.g. Starters, Demos, Experimental) into all template's .platform.template.yaml file (See below

3. Eliminate community contribution friction on templates

   • For the Priority Templates (Starters), continue separating what is tracked in template-builder vs what is tracked in a template's repository. This refers to having template builder track only PSH configuration files for a template while all other parts are tracked in the template's repository
   • Look into the Remote Project issue that might be surfaced when this (1) migration is complete.
   • Enable auto-merging opened sync PRs by including tests
   • ADD TEST: during template-builder monthly updates, deploy on eu-3 + another random region. Acts as an eu-3 test, template-builder auto-merge test, and a DoP button/initialize link test.

4. Notifications

   • Set up Slack notification channel for individual template open PRs and issues, or from the GitHub Project(s)

5. Migrate to auto-update process (and eu-3 to ca-1 migrations) for Demos class

6. Migrate to auto-update process (and eu-3 to ca-1 migrations) for Experimental class

7. Add relevant additional tests to individual templates

Template classes

From the conversation on Slack, we should move forward with the following class labelling in .platform.template.yaml files:

info:
    id: platformsh/TEMPLATE (Official/P.sh) OR vendor/TEMPLATE (Community)

    class: starter | demo | experimental | deprecated

    notes:
        - heading: "Features"
          content: |
                Node.js 12<br/>
                Postgres 12<br />
                Automatic TLS certificates<br />
                Yarn-based build<br />

[gilzow]

Going to include some wishlist items for future phases (expanding #7 from above)

• Integrate blackfire testing into the PR process
• Possibly add blackfire performance testing to see if we can spot performance degradation introduced in an update
• Add cypress end-to-end testing on templates (may need to determine where the overlap exists between blackfire and cypress)

[gilzow]

For Template Classes above, see #826

[gilzow]

@chadwcarlson
One other piece just came to mind while prepping phase 1: are we going to remove composer-level changes we make to a template on the template-builder side? For example, in D10, not only do we add the allow-plugins parts to the composer file, we also alter the name and description after pulling from the upstream.