Template updating improvements

[gilzow]

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

• [x] Migrate current set of priority templates from using auto-updating workflows to use reusable workflows
  • [x] 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
  • [x] Replace the current workflows in this repo with the new reusable workflow versions
• [x] 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.
• [x] 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.