Remove composer.lock during CI build for auto install of security patches.

[EarthlingDavey]

What do we need to do before removing composer.lock?

There is a risk that an update will introduce a bug or incompatibility.

Some packages will be more likely to introduce bugs than others. This will be based on the package's / author's

• test coverage.
• strictness of following semver.
• how far off the 'happy path' is our use of the package?
• are plugins dependant on each other.
• there will be other factors to consider.

One example is how the plugins: amazon-s3-and-cloudfront & wp-document-revisions can have an effect on each other. There is a current bug where amazon-s3-and-cloudfront logs a warning because of wp-document-revisions.

This minor incompatibility highlights that a similar thing could also arise in the future.

How do we mitigate incompatibilities from causing an issue?

• End to end test suite?
• Devs are notified when a new version of a package is rolled out.
• Regular QA with checkboxes for key functionality.

A good e2e test to start with would be uploading a document and ensuring that a revsion is created, and that the document is available for download.

[wilson1000]

The ideal situation, in my mind, is:

• Package dependency json files are committed to source with tracked versions, not *
• Lock files are removed from the repo
• CI automates a build 2 times a day, in the morning before work and in the afternoon around 2 pm
  • Code tests
  • Virus checks
  • Malicious code scan
  • Unit/feature tests
  • Docker image scan (Veracode/Snyk)
• If there is a change (compare SHA signatures?), devs are notified that Staging is waiting for review
• Perform review - both visual and functional (checklist needed for simplicity and process?)
• Rollback if needed: https://github.com/marketplace/actions/workflow-rollback, otherwise
• Deploy security patches and secure the application

We also have Sentry, Pingdom, Cloud Platform Kibana and Prometheus to flag issues.

Let's discuss 😄