From 990938b37d5aef03945fc27feab2236fc70a2511 Mon Sep 17 00:00:00 2001 From: Chris Reynolds Date: Wed, 31 Jul 2024 10:32:20 -0600 Subject: [PATCH 1/9] add a note front and center about release and non release commits --- README-internal.md | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/README-internal.md b/README-internal.md index 32c87cce..38492abb 100644 --- a/README-internal.md +++ b/README-internal.md @@ -1,5 +1,10 @@ # Working with the WordPress (Composer Managed) upstream +## "Release" and "non-release" commits +The composer-managed upstreams (including Drupal (Composer Managed)) have a idiosyncratic concept of "release" or "normal" commits and "non-release" commits. **Release** commits are those that affect files that are ultimately pushed to the `pantheon-upstreams` repository. This includes the everything that makes the base upstream work and _excludes_ any CI-related files, scripts or tests. **Non-release** commits are those that affect files that are not pushed to the `pantheon-upstreams` repository. This includes CI-related files, scripts, tests, and any other files that are not part of the base upstream. + +Because we tend to prefer Squash merges on PRs rather than Merge commits, it is vital to separate interests and not combine _release_ and _non-release_ commits in the same PR. Doing so will lead to portions of the PR being dropped when the deploy script is run, leading to a mismatch between the `pantheon-systems` and `pantheon-upstreams` repositories. + ## Cutting a new release 1. Update CHANGELOG.md. In the past, the copy has been created in consultation with the product owner. 1. Ensure the commit message for the last commit in this release says what we want to have appearing on the From 868609109c5080116868410dbd3f079c2c35f208 Mon Sep 17 00:00:00 2001 From: Chris Reynolds Date: Wed, 31 Jul 2024 10:33:12 -0600 Subject: [PATCH 2/9] update language in the differences section we don't actually discourage squash commits, so remove that. specify that the commit author is rewritten by automation --- README-internal.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/README-internal.md b/README-internal.md index 38492abb..7f8c9871 100644 --- a/README-internal.md +++ b/README-internal.md @@ -34,8 +34,8 @@ There are some atypical development and release procedures in use with this repo 1. Merging a PR to `default` _does not_ create a new release of `pantheon-upstreams/wordpress-composer-managed`. This allows us to batch more than one relatively small change into a single new "release" such that the number of separate update events appearing on customer dashboards is more controlled. ### Differences between `pantheon-upstreams` and `pantheon-systems` repos: - 1. Commits modifying any of the following files and directories are omitted from `pantheon-upstreams`: `.circleci`, `devops`, `.github`, `README-internal.md`. This prevents downstream Pantheon sites from being littered with our internal CI configuration, and allows us to enhance CI without generating irrelevant site updates. However, it means **you must not create commits that modify both automation and other files** in the same commit. For this reason **squash commits are discouraged** (as they can contain changes to multiple files). - 2. Commit authors appear on the dashboard. For this reason, they are rewritten to `Pantheon Automation `. + 1. Commits modifying any of the following files and directories are omitted from `pantheon-upstreams`: `.circleci`, `devops`, `.github`. This prevents downstream Pantheon sites from being littered with our internal CI configuration, and allows us to enhance CI without generating irrelevant site updates. However, it means **you must not create commits that modify both automation and other files** in the same commit. + 2. Commit authors appear on the dashboard. For this reason, they are rewritten to `Pantheon Automation ` by automation. ## Automation demystified The following workflows run on this repository: From 5202d0f9efd95bf981cb2166e1789b32117c5fc8 Mon Sep 17 00:00:00 2001 From: Chris Reynolds Date: Wed, 31 Jul 2024 10:33:30 -0600 Subject: [PATCH 3/9] update ci.yml documentation --- README-internal.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README-internal.md b/README-internal.md index 7f8c9871..ef78a45b 100644 --- a/README-internal.md +++ b/README-internal.md @@ -44,7 +44,7 @@ The following workflows run on this repository: * There is only one CircleCI workflow, [`.circleci/config.yml`](.circleci/config.yml). This workflow runs on merge to `release` and handles the deployment of the new release to the `pantheon-upstreams` repositories. See the `devops` folder for the scripts that are run as part of this workflow. ### GitHub Actions -* `ci.yml` - This runs the `Lint and Test` job on pull requests. It runs on PHP 8.x (Roots Bedrock does not support < PHP 8). There are no tests configured, so while `composer test` is run, it does not actually do anything. +* `ci.yml` - This runs the `Lint and Test` job on pull requests. It runs on PHP 8.1-8.3 (Roots Bedrock does not support < PHP 8.1). Playwright tests are run in `playwright.yml` only after `ci.yml` determines that there are no linting issues. Additionally, `ci.yml` adds the commit checking workflow that is normally run on CircleCI to ensure that there are no non-release commits mixed with release commits in a single branch. There are no tests configured in the upstream itself, so while `composer test` is run, it does not actually do anything. * `composer-diff.yml` - This runs the `Composer Diff` job on pull requests. It compares the `composer.lock` file in the pull request to the `composer.lock` file in the `default` branch. If there are differences, it will comment on the pull request with the differences. * `sage-test.yml` - This workflow only runs when changes have been made to any of the scripts in `private/scripts` (TODO: if we add more scripts to this directory, we might want to change this behavior to be more specific) or to the workflow file itself. It spins up a new multidev on the `wpcm-sage-install-tests` site on Pantheon and attempts to run `composer install-sage` script. The tests run on `ubuntu-latest` and `macos-latest` environments. (Windows environments need WSL2 to run the script which should broadly be covered by `ubuntu-latest`.) * `sync-default.yml` - This workflow syncs the `default` branch to `main` in the `pantheon-systems/wordpress-composer-managed` repository. This is used for the [WordPress (Composer Managed) Nightly Canary](https://github.com/pantheon-systems/composer-managed-nightly-canaries). The canary is an automated workflow that spins up a brand new site on Pantheon off of the `default` branch of this repository and runs some basic tests to ensure that the site can be created and that the `composer install` script runs successfully. If the canary site fails to build, an update is posted to the `#cms-ecosystem-repos` channel in Slack. From 4ec587743bccc5aee32833657148e835b0f5db87 Mon Sep 17 00:00:00 2001 From: Chris Reynolds Date: Wed, 31 Jul 2024 10:33:41 -0600 Subject: [PATCH 4/9] add new section about playwright tests --- README-internal.md | 1 + 1 file changed, 1 insertion(+) diff --git a/README-internal.md b/README-internal.md index ef78a45b..9546911a 100644 --- a/README-internal.md +++ b/README-internal.md @@ -48,6 +48,7 @@ The following workflows run on this repository: * `composer-diff.yml` - This runs the `Composer Diff` job on pull requests. It compares the `composer.lock` file in the pull request to the `composer.lock` file in the `default` branch. If there are differences, it will comment on the pull request with the differences. * `sage-test.yml` - This workflow only runs when changes have been made to any of the scripts in `private/scripts` (TODO: if we add more scripts to this directory, we might want to change this behavior to be more specific) or to the workflow file itself. It spins up a new multidev on the `wpcm-sage-install-tests` site on Pantheon and attempts to run `composer install-sage` script. The tests run on `ubuntu-latest` and `macos-latest` environments. (Windows environments need WSL2 to run the script which should broadly be covered by `ubuntu-latest`.) * `sync-default.yml` - This workflow syncs the `default` branch to `main` in the `pantheon-systems/wordpress-composer-managed` repository. This is used for the [WordPress (Composer Managed) Nightly Canary](https://github.com/pantheon-systems/composer-managed-nightly-canaries). The canary is an automated workflow that spins up a brand new site on Pantheon off of the `default` branch of this repository and runs some basic tests to ensure that the site can be created and that the `composer install` script runs successfully. If the canary site fails to build, an update is posted to the `#cms-ecosystem-repos` channel in Slack. +* `playwright.yml` - This runs a suite of "hello world" style tests on fixture sites on the Pantheon platform using [Playwright](https://playwright.dev/). These tests were adapted from the [Composer Managed Nightly Canaries](https://github.com/pantheon-systems/composer-managed-nightly-canaries) tests originally developed by the Decoupled Kit team. The workflows set up new single site WordPress or subdirectory multisite WordPress sites using the Composer Managed upstream, copy files from the PR over to the new site, and install and run the Playwright tests. In the case of subdomain multisite, a single fixture site is maintained due to the complexity of setting up subdomains in automation. ## Branch protections and their rationale From 4fbc45cb9b89705972e8657bd3ccd1f39538905e Mon Sep 17 00:00:00 2001 From: Chris Reynolds Date: Wed, 31 Jul 2024 10:35:55 -0600 Subject: [PATCH 5/9] add section about phpcbf action --- README-internal.md | 1 + 1 file changed, 1 insertion(+) diff --git a/README-internal.md b/README-internal.md index 9546911a..bf993290 100644 --- a/README-internal.md +++ b/README-internal.md @@ -49,6 +49,7 @@ The following workflows run on this repository: * `sage-test.yml` - This workflow only runs when changes have been made to any of the scripts in `private/scripts` (TODO: if we add more scripts to this directory, we might want to change this behavior to be more specific) or to the workflow file itself. It spins up a new multidev on the `wpcm-sage-install-tests` site on Pantheon and attempts to run `composer install-sage` script. The tests run on `ubuntu-latest` and `macos-latest` environments. (Windows environments need WSL2 to run the script which should broadly be covered by `ubuntu-latest`.) * `sync-default.yml` - This workflow syncs the `default` branch to `main` in the `pantheon-systems/wordpress-composer-managed` repository. This is used for the [WordPress (Composer Managed) Nightly Canary](https://github.com/pantheon-systems/composer-managed-nightly-canaries). The canary is an automated workflow that spins up a brand new site on Pantheon off of the `default` branch of this repository and runs some basic tests to ensure that the site can be created and that the `composer install` script runs successfully. If the canary site fails to build, an update is posted to the `#cms-ecosystem-repos` channel in Slack. * `playwright.yml` - This runs a suite of "hello world" style tests on fixture sites on the Pantheon platform using [Playwright](https://playwright.dev/). These tests were adapted from the [Composer Managed Nightly Canaries](https://github.com/pantheon-systems/composer-managed-nightly-canaries) tests originally developed by the Decoupled Kit team. The workflows set up new single site WordPress or subdirectory multisite WordPress sites using the Composer Managed upstream, copy files from the PR over to the new site, and install and run the Playwright tests. In the case of subdomain multisite, a single fixture site is maintained due to the complexity of setting up subdomains in automation. +* `phpcbf.yml` - This runs the `PHP Code Beautifier and Fixer` job on pull requests. It runs on all PRs, commits the changes back to the PR and adds a comment on the pull request if it changed anything. Note that `phpcbf` does not fix _all_ linting issues, and things that `phpcbf` cannot fix will still need to be fixed manually. ## Branch protections and their rationale From e9befba243d7c2a533b091fb69fec85100f477e5 Mon Sep 17 00:00:00 2001 From: Pantheon Robot Date: Wed, 31 Jul 2024 16:42:27 +0000 Subject: [PATCH 6/9] PHPCBF: Fix coding standards --- config/application.php | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/config/application.php b/config/application.php index 275a32c2..5d57c4b2 100644 --- a/config/application.php +++ b/config/application.php @@ -62,9 +62,9 @@ /** * Custom Content Directory */ -Config::define('CONTENT_DIR', '/app'); -Config::define('WP_CONTENT_DIR', $webroot_dir . Config::get('CONTENT_DIR')); -Config::define('WP_CONTENT_URL', Config::get('WP_HOME') . Config::get('CONTENT_DIR')); +Config::define( 'CONTENT_DIR', '/app' ); +Config::define( 'WP_CONTENT_DIR', $webroot_dir . Config::get( 'CONTENT_DIR' ) ); +Config::define( 'WP_CONTENT_URL', Config::get( 'WP_HOME' ) . Config::get( 'CONTENT_DIR' ) ); /** * DB settings From 8f84172c063207d921ee8ad74fed3a41ebbc342a Mon Sep 17 00:00:00 2001 From: Phil Tyler Date: Wed, 31 Jul 2024 12:58:23 -0700 Subject: [PATCH 7/9] Update README-internal.md --- README-internal.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README-internal.md b/README-internal.md index bf993290..eb60b0e0 100644 --- a/README-internal.md +++ b/README-internal.md @@ -1,7 +1,7 @@ # Working with the WordPress (Composer Managed) upstream ## "Release" and "non-release" commits -The composer-managed upstreams (including Drupal (Composer Managed)) have a idiosyncratic concept of "release" or "normal" commits and "non-release" commits. **Release** commits are those that affect files that are ultimately pushed to the `pantheon-upstreams` repository. This includes the everything that makes the base upstream work and _excludes_ any CI-related files, scripts or tests. **Non-release** commits are those that affect files that are not pushed to the `pantheon-upstreams` repository. This includes CI-related files, scripts, tests, and any other files that are not part of the base upstream. +The composer-managed upstreams (including Drupal (Composer Managed)) have a idiosyncratic concept of "release" or "normal" commits and "non-release" commits. **Release** commits are those that affect files that are ultimately pushed to the `pantheon-upstreams` repository. This includes everything that makes the base upstream work and _excludes_ any CI-related files, scripts or tests. **Non-release** commits are those that affect files that are not pushed to the `pantheon-upstreams` repository. This includes CI-related files, scripts, tests, and any other files that are not part of the base upstream. Because we tend to prefer Squash merges on PRs rather than Merge commits, it is vital to separate interests and not combine _release_ and _non-release_ commits in the same PR. Doing so will lead to portions of the PR being dropped when the deploy script is run, leading to a mismatch between the `pantheon-systems` and `pantheon-upstreams` repositories. From 9015653db9fa865025ee24fe120451226613f4bf Mon Sep 17 00:00:00 2001 From: Chris Reynolds Date: Wed, 31 Jul 2024 14:03:10 -0600 Subject: [PATCH 8/9] alter "commits" to "file changes" Co-authored-by: Phil Tyler --- README-internal.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README-internal.md b/README-internal.md index eb60b0e0..07123b4f 100644 --- a/README-internal.md +++ b/README-internal.md @@ -44,7 +44,7 @@ The following workflows run on this repository: * There is only one CircleCI workflow, [`.circleci/config.yml`](.circleci/config.yml). This workflow runs on merge to `release` and handles the deployment of the new release to the `pantheon-upstreams` repositories. See the `devops` folder for the scripts that are run as part of this workflow. ### GitHub Actions -* `ci.yml` - This runs the `Lint and Test` job on pull requests. It runs on PHP 8.1-8.3 (Roots Bedrock does not support < PHP 8.1). Playwright tests are run in `playwright.yml` only after `ci.yml` determines that there are no linting issues. Additionally, `ci.yml` adds the commit checking workflow that is normally run on CircleCI to ensure that there are no non-release commits mixed with release commits in a single branch. There are no tests configured in the upstream itself, so while `composer test` is run, it does not actually do anything. +* `ci.yml` - This runs the `Lint and Test` job on pull requests. It runs on PHP 8.1-8.3 (Roots Bedrock does not support < PHP 8.1). Playwright tests are run in `playwright.yml` only after `ci.yml` determines that there are no linting issues. Additionally, `ci.yml` adds the commit checking workflow that is normally run on CircleCI to ensure that there are no non-release file changes mixed with release changes in a single commit. There are no tests configured in the upstream itself, so while `composer test` is run, it does not actually do anything. * `composer-diff.yml` - This runs the `Composer Diff` job on pull requests. It compares the `composer.lock` file in the pull request to the `composer.lock` file in the `default` branch. If there are differences, it will comment on the pull request with the differences. * `sage-test.yml` - This workflow only runs when changes have been made to any of the scripts in `private/scripts` (TODO: if we add more scripts to this directory, we might want to change this behavior to be more specific) or to the workflow file itself. It spins up a new multidev on the `wpcm-sage-install-tests` site on Pantheon and attempts to run `composer install-sage` script. The tests run on `ubuntu-latest` and `macos-latest` environments. (Windows environments need WSL2 to run the script which should broadly be covered by `ubuntu-latest`.) * `sync-default.yml` - This workflow syncs the `default` branch to `main` in the `pantheon-systems/wordpress-composer-managed` repository. This is used for the [WordPress (Composer Managed) Nightly Canary](https://github.com/pantheon-systems/composer-managed-nightly-canaries). The canary is an automated workflow that spins up a brand new site on Pantheon off of the `default` branch of this repository and runs some basic tests to ensure that the site can be created and that the `composer install` script runs successfully. If the canary site fails to build, an update is posted to the `#cms-ecosystem-repos` channel in Slack. From 0d001a3272d2e64d94d4f4dbde8bbad74e1e3fef Mon Sep 17 00:00:00 2001 From: Chris Reynolds Date: Wed, 31 Jul 2024 14:05:28 -0600 Subject: [PATCH 9/9] add clarification about allowing release + non-release changes in the same PR --- README-internal.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README-internal.md b/README-internal.md index 07123b4f..6bb84904 100644 --- a/README-internal.md +++ b/README-internal.md @@ -3,7 +3,7 @@ ## "Release" and "non-release" commits The composer-managed upstreams (including Drupal (Composer Managed)) have a idiosyncratic concept of "release" or "normal" commits and "non-release" commits. **Release** commits are those that affect files that are ultimately pushed to the `pantheon-upstreams` repository. This includes everything that makes the base upstream work and _excludes_ any CI-related files, scripts or tests. **Non-release** commits are those that affect files that are not pushed to the `pantheon-upstreams` repository. This includes CI-related files, scripts, tests, and any other files that are not part of the base upstream. -Because we tend to prefer Squash merges on PRs rather than Merge commits, it is vital to separate interests and not combine _release_ and _non-release_ commits in the same PR. Doing so will lead to portions of the PR being dropped when the deploy script is run, leading to a mismatch between the `pantheon-systems` and `pantheon-upstreams` repositories. +Because we tend to prefer Squash merges on PRs rather than Merge commits, it is vital to separate interests and not combine _release_ and _non-release_ commits in the same PR. Doing so will lead to portions of the PR being dropped when the deploy script is run, leading to a mismatch between the `pantheon-systems` and `pantheon-upstreams` repositories. Multiple commits in a single PR that keep the division between _release_ and _non-release_ are allowed, **but should not be squash merged.** ## Cutting a new release 1. Update CHANGELOG.md. In the past, the copy has been created in consultation with the product owner.