Test new deployment pipeline

[warrensearle]

This issue is purely to test the new deployment pipeline. Feel free to ignore.

We will be checking that:

• Pull request. Creating and updating a PR causes the test job to run and, if requested, deploys a preview url
• Pull request. Updating the PR comment to include PREVIEW:DEVELOP deploys a preview to the develop environment
• Pull request. Updating the PR comment to include PREVIEW:STAGING deploys a preview to the staging environment
• Pull request. Updating the PR comment to include PREVIEW:OFF does not deploy a preview
• Merge. Merging a PR into main bumps the package version number (if not already bumped)
• Merge. Merging a PR into main causes draft release notes to be updated
• Merge. Merging a PR into main deploys the latest draft to staging
• Publishing a draft release deploys the latest to production
• Using manual workflow Deploy to Production we can roll back to a previous version
• Using manual workflow Deploy to Production we can roll forwards to another version

[warrensearle]

Hey @tomlovesgithub and @mbrookeswebdev I wonder if you would each test the above on Assessments.
In my testing I just made a change to the readme.md file (included an extra line break) in order to create the PR and take it through the pipeline.

Things to check

• Pull request. Creating and updating a PR causes the test job to run and, if requested, deploys a preview url
• Pull request. Updating the PR comment to include PREVIEW:DEVELOP deploys a preview to the develop environment
• Pull request. Updating the PR comment to include PREVIEW:STAGING deploys a preview to the staging environment
• Pull request. Updating the PR comment to include PREVIEW:OFF does not deploy a preview
• Merge. Merging a PR into main bumps the package version number (if not already bumped)
• Merge. Merging a PR into main causes draft release notes to be updated
• Merge. Merging a PR into main deploys the latest draft to staging
• Publishing a draft release deploys the latest to production
• Using manual workflow Deploy to Production we can roll back to a previous version
• Using manual workflow Deploy to Production we can roll forwards to another version

[mbrookeswebdev]

@warrensearle
Hi Warren,

Tom and I both tested it, for me most steps worked but I have a few questions with regards to the process:

1. What should we see if PREVIEW:OFF is selected? I've had a staging preview url from the previous step and when I chose PREVIEW:OFF nothing happened, the staging url was still displaying. I thought it might disappear if it is OFF.

2. What should happen after the rollback process is complete? We've run the workflow to rollback to 0.14.0 from 0.15.0 and current release still shows 0.15.0 and I can't see any code changes.

[warrensearle]

Thank you @mbrookeswebdev

What should we see if PREVIEW:OFF is selected? I've had a staging preview url from the previous step and when I chose PREVIEW:OFF nothing happened, the staging url was still displaying. I thought it might disappear if it is OFF.

If a preview has already been created then setting PREVIEW:OFF doesn't do anything, other than stop the preview from being updated.
It is more useful, say, when you create the PR and don't want the preview to be generated.
Note: if you wanted to turn previews off but have an old one hanging around you can delete the preview comment, as well as use PREVIEW:OFF

What should happen after the rollback process is complete? We've run the workflow to rollback to 0.14.0 from 0.15.0 and current release still shows 0.15.0 and I can't see any code changes.

The roll back is to change which version is currently deployed to production, rather than change the code. So yes we could have a situation where the latest release in code is 0.15.0 but deployed live is 0.13.0 or any version you like.