Merge pull request #766 from massgov/release-5.18.0

Release 5.18.0

.circleci/config.yml

@@ -31,8 +31,6 @@ jobs:
       - persist_to_workspace:
           root: /var/www
           paths: [code]
-      - store_artifacts:
-          path: /var/www/code/styleguide/public/assets
 
   test:
     working_directory: /home/circleci/code
@@ -55,7 +53,7 @@ jobs:
       - store_test_results:
           path: backstopjs/reports/ci
 
-  deploy_artifacts:
+  deploy_branch:
     <<: *common_config
     steps:
       - attach_workspace: {at: /var/www}
@@ -64,37 +62,41 @@ jobs:
           command: |
             git config --global user.email "[email protected]"
             git config --global user.name "MassGov Bot"
-      # @todo: We shouldn't need global gulp from the build scripts.
-      - run: { name: 'Gulp Install', command: 'yarn global add gulp' }
-      - run: { name: 'Deploy', command: 'cd styleguide && vendor/bin/phing deploy' }
+      - run: { name: 'Deploy artifacts', command: "cd styleguide && node_modules/.bin/gulp artifacts:publish" }
+      - run: { name: 'Deploy S3', command: "cd styleguide && node_modules/.bin/gulp patternlab:publish" }
 
-  deploy_cd:
+  deploy_tag:
     <<: *common_config
     steps:
       - attach_workspace: {at: /var/www}
-      # @todo: We shouldn't need global gulp from the build scripts.
-      - run: { name: 'Gulp Install', command: 'yarn global add gulp' }
-      - run: { name: 'S3 Deployment', command: 'cd styleguide && ../scripts/deploy-s3.sh -b ${CIRCLE_BRANCH}' }
+      - run:
+          name: "Prepare Git"
+          command: |
+            git config --global user.email "[email protected]"
+            git config --global user.name "MassGov Bot"
+      - run: { name: 'Configure NPM', command: 'echo "//registry.npmjs.org/:_authToken=${NPM_TOKEN}" > ~/.npmrc'}
+      - run: { name: 'Release Artifacts', command: "cd styleguide && node_modules/.bin/gulp artifacts:release" }
+      - run: { name: 'Release S3', command: "cd styleguide && node_modules/.bin/gulp patternlab:release" }
+      - run: { name: 'Release NPM', command: "cd styleguide && node_modules/.bin/gulp npm:release" }
 
 workflows:
   version: 2
-  build_deploy:
+  build_branch:
     jobs:
-      - build:
-          filters:
-            tags:
-              only: /\bv?(?:0|[1-9]\d*)\.(?:0|[1-9]\d*)\.(?:0|[1-9]\d*)(?:-[\da-z\-]+(?:\.[\da-z\-]+)*)?(?:\+[\da-z\-]+(?:\.[\da-z\-]+)*)?\b/
+      - build
       - test:
           requires: [build]
-      - deploy_artifacts:
+      - deploy_branch:
           requires: [build]
+
+  build_tag:
+    jobs:
+      - build:
           filters:
-            branches:
-              ignore: /.*/
-            tags:
-              only: /\bv?(?:0|[1-9]\d*)\.(?:0|[1-9]\d*)\.(?:0|[1-9]\d*)(?:-[\da-z\-]+(?:\.[\da-z\-]+)*)?(?:\+[\da-z\-]+(?:\.[\da-z\-]+)*)?\b/
-      - deploy_cd:
+            branches: { ignore: /.*/ }
+            tags: { only: /.*/ }
+      - deploy_tag:
           requires: [build]
           filters:
-            branches:
-              ignore: /^master$/
+            branches: { ignore: /.*/ }
+            tags: { only: /.*/ }

docs/release.md

@@ -7,13 +7,12 @@ Mayflower release managers with the necessary repo permissions can follow these
 1. Check out the [massgov/mayflower `dev` branch](https://github.com/massgov/mayflower/commits/dev): `git checkout dev` and pull the latest from upstream `git pull upstream dev`. (This assumes that your massgov/mayflower remote repo is named `upstream`)
 1. Create a release branch `git checkout -b release-#.#.#` where `#.#.#` is the next version (i.e. `5.0.0`).  Read more about [Mayflower and semantic versioning](docs/versioning.md) to ensure that your are creating the right type of version.
 1. Add [release notes](https://github.com/massgov/mayflower/blob/dev/docs/change-log-instructions.md) to the top of [release notes](/release-notes.md) based on the "changelog.txt" files, remove all the "changelog.txt" files and then commit.
-1. Move into the `stylguide` directory `cd styleguide` (may be a good idea to run `npm install` in case the release includes new packages).
-1. Bump the version on the homepage - `@pages/readme2.json` - by updating the version and date text in `errorPage.type`
-1. Bump the version of the npm package by running `gulp bump -v=#.#.#` where `#.#.#` is the version you are releasing.
-1. Commit your version bump file updates.
+1. Move into the `styleguide` directory `cd styleguide` and run `npm install` in case the release includes new packages.
+1. Update the version of the npm package by editing the `version` field in `package.json`.
+1. Commit your version bump file update.
 1. Push release branch to `massgov/mayflower` (i.e. `git push upstream release-#.#.#`).
 1. Wait for [the circle build](https://circleci.com/gh/massgov/mayflower) to pass, which will deploy your release branch to staging automagically :).
-1. Verify release notes against the site rendered at: `https://mayflower.digital.mass.gov/<your-release-branch>/index.html`.
+1. Verify release notes against the site rendered at: `https://mayflower.digital.mass.gov/b/<your-release-branch>/index.html`.
 1. Smoke test Mayflower (a quick way to do this is to browse around to some of the different pages in the "pages" menu and do a quick gut check)
 1. Open a Github Pull Request to merge (no squash!) the release branch into the `master` branch.
     1. Add the relevant release notes to the PR notes.
@@ -24,23 +23,9 @@ Mayflower release managers with the necessary repo permissions can follow these
     1. Release title: `#.#.#` (your release number)
     1. Describe the release: paste your release notes markdown here, after the release version/date line, add a link to the release PR (protip: type `#` and you'll get an autocomplete dropdown to get to your pr)
 1. Wait for [the circle builds](https://circleci.com/gh/massgov/mayflower) to pass
-1. Pull down master `git pull upstream master`
-1. Check out master `git checkout master`
-1. Pull down your tag `git fetch --tags`
-1. Make sure you are in `styleguide` (cd into `styleguide` if you're not)
-1. Make sure you are have the necessary credentials for the s3 bucket and npm:
-    1. In order to push to the mayflower s3 bucket, you need to have credentials set up in `<mayflower>/styleguide/tools/gulp/local.js` (you can copy `local.js.example` as a model).  Ask a team member for help with credentials.
-    1. In order to push the Mayflower package to [NPM](https://npmjs.com/@massds/mayflower), you need to be authenticated on NPM, by one of the following:
-        1. Having an `.npmrc` file with credentials for the `@massds` account (or your own NPM account if you're added to the Mayflower package as an owner) in the styleguide directory of your Mayflower repo (this file is not and should not be versioned -- ask a team member for credentials)
-            - See [npmjs docs re: .npmrc](https://docs.npmjs.com/files/npmrc#per-project-config-file\n\n2)
-        1. Having an `NPM_TOKEN` environment variable for `@massds`
-            - See [npmjs docs re: NPM_TOKEN](http://blog.npmjs.org/post/118393368555/deploying-with-npm-private-modules)
-        1. Authenticating from the npm CLI (Note: you must be added to the Mayflower NPM package project as an owner -- ask a team member for help)
-            - See [npmjs docs](https://docs.npmjs.com/getting-started/publishing-npm-packages#preparation)
-1. Deploy the release (to its three locations: prod `/`, current version `/<your-tag-name>/`, and latest minor `/<current-major-version>/`) and publish the [@massds/mayflower package on NPM](https://www.npmjs.com/package/@massds/mayflower) by running `../scripts/deploy-mayflower.sh -b <your-tag-name>` and follow the prompts.
 1. Smoke test [Prod](http://mayflower.digital.mass.gov)
     - Make sure the home page reflects the date and version
-1. Open a GitHub Pull Request to merge `master` into `develop` (this should only bring an updated `release-notes.md`, `@pages/readme2.json`). If a feature was reverted on the release branch, have a peer do the merge after a review.
+1. Open a GitHub Pull Request to merge `master` into `dev` (this should only bring an updated `release-notes.md`, `package.json`). If a feature was reverted on the release branch, have a peer do the merge after a review.
 1. In JIRA Go to the [DP project](https://jira.state.ma.us/projects/DP/).
     1. Click on the Releases icon on the left side (it looks like a boat/ship).
     1. Add a new release version with today's date.
@@ -54,9 +39,6 @@ In the event that a release needs to be rolled back from production, follow thes
 
 1. Pull down and checkout the prior release tag and check it out by running `git pull --tags` then `git checkout <prior-release-tag>` (*Note: you should see a message from git that you are in a [detached head state](https://www.git-tower.com/learn/git/faq/detached-head-when-checkout-commit) and that is okay.*)
 1. Make sure you are in `/styleguide` directory
-1. Deploy prior release tag to:
-    1. [Prod](http://mayflower.digital.mass.gov) by running `../scripts/deploy-prod-s3.sh -b <prior-release-tag>`
-        1. When prompted, confirm your prod deployment by typing: `y`
-    1. Latest minor by running `../scripts/deploy-latest-minor-s3.sh -b <prior-release-tag>`
-        1. When prompted, confirm your latest minor deployment by typing: `y`
+1. Deploy prior release tag to S3 (note: you must have the S3 credentials to do this):
+    1. `gulp patternlab:release`
 1. Validate rollback by browsing to [Prod](http://mayflower.digital.mass.gov) as well as `https://mayflower.digital.mass.gov/<current-major>/` and verifying that the home page reflects the correct version

docs/s3-architecture.md

@@ -9,8 +9,7 @@ We host Mayflower (i.e. the static output of a Pattern Lab “build”) in an am
 |Name|URL path|Example|Purpose|What code gets deployed here?|When does code get deployed here?|How does code get deployed here?|Permanent or temporary?|
 |---|---|---|---|---|---|---|---|
 |**Production**|/|mayflower.digital.mass.gov/|The latest and greatest version of Mayflower.  Mostly used for browsing and (soon) implementation documentation from the home page.|Pattern Lab build artifacts from a production tag (i.e. 5.10.0) cut off master branch..|During the release process, when a release branch is merged into master.|Release manager executes a script command.  See release docs.|Permanent (and dynamic, i.e. the contents change when a new release is deployed here)|
-|**Latest minor**|/<current-major-#>/|/5/|The latest minor version within a given major: implementers who link to these css/js/font/icon assets get safe updates automatically|Pattern Lab build artifacts from a production tag (i.e. 5.10.0) cut off master branch. Note: if the production tag starts a new major release, then a new /<current-major-#> directory will be created automatically.|During the release process, when a release branch is merged into master.|Release manager executes a script command.  See release docs.|Permanent (and dynamic, i.e. the contents change when a new release is deployed here)|
-|**Release**|/<#.#.#>/|/5.10.0/|Static snapshot of a given release: implementers who link to these css/js/font/icon assets get updates only when they manually change their links to the next version|Pattern Lab build artifacts from a production tag (i.e. 5.10.0) cut off master branch..|During the release process, when a release branch is merged into master.|Release manager executes a script command.  See release docs.|Permanent (and static, i.e. once is a release is deployed here it will never change)|
-|**Staging**|/release-#.#.#/|/release-5.11.0/|A given release branch; used to stage an upcoming release for functional / integration testing.|Pattern Lab build artifacts from the release branch.|When a release branch (which has an open PR) has a new commit pushed.|CircleCI deploys as part of build for the release branch.|Temporary (can be deleted when the release testing is done) @TODO script this|
-|**Dev**|/dev/|/dev/|Bleeding edge of our codebase; used for browsing all of the code that has been merged into dev branch prior to release.|Pattern Lab build artifacts from the dev branch. |When a feature PR is squashed and merged into dev branch.|CircleCI deploys as part of build for the  dev branch.|Permanent (and dynamic, i.e. the contents change when new work is merged in)|
-|**Feature branch**|/<my-branch-name>/|/DP-1234-my-ticket/|The feature development done on a particular branch; used for internal and external review functional tests.|Pattern Lab build artifacts from the feature branch.|When a feature branch (which has an open PR) has a new commit pushed.|CircleCI deploys as part of build for the feature branch.|Temporary (can be deleted when the feature testing is done) @TODO script this
+|**Latest minor**|/v/<current-major-#>/|/v/5/|The latest minor version within a given major: implementers who link to these css/js/font/icon assets get safe updates automatically|Pattern Lab build artifacts from a production tag (i.e. 5.10.0) cut off master branch. Note: if the production tag starts a new major release, then a new /<current-major-#> directory will be created automatically.|During the release process, when a release branch is merged into master.|Release manager executes a script command.  See release docs.|Permanent (and dynamic, i.e. the contents change when a new release is deployed here)|
+|**Staging**|/b/release-#.#.#/|/b/release-5.11.0/|A given release branch; used to stage an upcoming release for functional / integration testing.|Pattern Lab build artifacts from the release branch.|When a release branch (which has an open PR) has a new commit pushed.|CircleCI deploys as part of build for the release branch.|Temporary (can be deleted when the release testing is done) @TODO script this|
+|**Dev**|/b/dev/|/b/dev/|Bleeding edge of our codebase; used for browsing all of the code that has been merged into dev branch prior to release.|Pattern Lab build artifacts from the dev branch. |When a feature PR is squashed and merged into dev branch.|CircleCI deploys as part of build for the  dev branch.|Permanent (and dynamic, i.e. the contents change when new work is merged in)|
+|**Feature branch**|/b/<my-branch-name>/|/b/DP-1234-my-ticket/|The feature development done on a particular branch; used for internal and external review functional tests.|Pattern Lab build artifacts from the feature branch.|When a feature branch (which has an open PR) has a new commit pushed.|CircleCI deploys as part of build for the feature branch.|Temporary (can be deleted when the feature testing is done) @TODO script this

release-notes.md

@@ -13,6 +13,27 @@ The format is based on [Keep a Changelog](http://keepachangelog.com/en/1.0.0/)
 **For example**
 - DP-1234: The short description text on a [service detail](http://mayflower.digital.mass.gov/?p=pages-detail-for-service-howto-location) page banner ([@organisms/by-template/page-banner](http://mayflower.digital.mass.gov/?p=organisms-page-banner)) should now render ([PR #493](https://github.com/massgov/mayflower/pull/493))
 
+## 5.18.0 (4/5/2018)
+
+### Added 
+- DP-7564: Fixes issue with black line over "Who we serve" stacked row on Elected org page. Fixes issue with media queries on Elected org page.
+- DP-8051: Adds page banner variation for use in elected and org detail pages.
+- DP-8176: People in curated lists
+
+### Changed
+- DP-7483: Organization block list fix.
+- DP-8221: Truncates featured item titles past character limit.
+- DP-8339: Automate the release process for Mayflower.
+- DP-8402: Use dynamic Pattern Lab variables to reduce the amount of files that need to change during the release workflow.
+- DP-8455: Make image URLs optional on search banner to allow setting randomized image in javascript.
+
+### Fixed 
+- DP-7624: Adds cover page example of binder
+- DP-8126: Avoid making two ajax calls to the same endpoint when there are two ajax patterns on the same page.
+- DP-8378: Fix the page banner display issue in mobile for Topic, Organizaion and Service pages.
+- DP-8400: Add fix for binder page jumplinks.
+- DP-8436: Moves post content for information details and fixes handling text in sticky header after toc jump link is clicked.
+
 ## 5.17.0 (3/29/2018)
 
 ### Added

scripts/deploy-latest-minor-s3.sh

@@ -18,12 +18,11 @@
 # 1. Validate the passed arguments: build source
 # 2. Attempt to checkout passed build source
 # 3. Get to mayflower/styleguide directory
-# 4. Write config to support hosting from subdirectory, if necessary
-# 5. Build pattern lab static assets
-# 6. Copy static assets (build output: styleguide/public/) into a new temp directory
-# 7. Execute gulp command to deploy to s3
-# 8. Remove the temp directory
-# 9. Check out the previous branch
+# 4. Build pattern lab static assets
+# 5. Copy static assets (build output: styleguide/public/) into a new temp directory
+# 6. Execute gulp command to deploy to s3
+# 7. Remove the temp directory
+# 8. Check out the previous branch
 
 # Default variables
 buildSrc=false
@@ -79,27 +78,10 @@ checkoutBuildSource "$buildSrc"
 # 3. Get to styleguide directory
 cdStyleguide
 
-# 4. Set the domain and asset path config
-# If we're deploying something that doesn't have the url.json.example file, create it first
-createUrlJson
+# 4. Build pattern to generate prod static assets
+buildMayflower "https://mayflower.digital.mass.gov/$majorVersion"
 
-# Determine the url.assetsPath based arguments passed
-# For root deploy (production):  url.assetsPath = assets (already set by default)
-# For latest minor deploy: = url.assetsPath = <latest minor determined by build source tag>/assets
-# For all other deploys: url.assetsPath = <build source branch or tag name>/assets
-
-domain="https://mayflower.digital.mass.gov"
-# Set up the config value for assetsPath
-subDir="$majorVersion" #$majorVersion is set above when we validate the prod tag
-assetsPath="$subDir/assets"
-
-# Set url.domain and url.assetsPath
-writeAssetsPathConfig "$domain" "$assetsPath"
-
-# 5. Build pattern to generate prod static assets
-buildMayflower
-
-# 6. Copy built assets in /public into new tmp directory
+# 5. Copy built assets in /public into new tmp directory
 
 # Make temp directory to copy public assets
 line="Making ~/tmp/mayflower/$subDir directory..."

scripts/deploy-prod-s3.sh

@@ -16,12 +16,11 @@
 # 1. Validate the passed arguments: build source
 # 2. Attempt to checkout passed build source
 # 3. Get to mayflower/styleguide directory
-# 4. Write config for domain and assetsPath values
-# 5. Build pattern lab static assets
-# 6. Copy static assets (build output: styleguide/public/) into a new temp directory
-# 7. Execute gulp command to deploy to s3
-# 8. Remove the temp directory
-# 9. Check out the previous branch
+# 4. Build pattern lab static assets
+# 5. Copy static assets (build output: styleguide/public/) into a new temp directory
+# 6. Execute gulp command to deploy to s3
+# 7. Remove the temp directory
+# 8. Check out the previous branch
 
 # Default argument values
 buildSrc=false
@@ -76,23 +75,8 @@ checkoutBuildSource "$buildSrc"
 # 3. Get to styleguide directory
 cdStyleguide
 
-# 4. Set the domain and asset path config
-# If we're deploying something that doesn't have the url.json.example file, create it first
-createUrlJson
-
-# Determine the url.assetsPath based arguments passed
-# For root deploy (production):  url.assetsPath = assets
-# For latest minor deploy: = url.assetsPath = <latest minor determined by build source tag>/assets
-# For all other deploys: url.assetsPath = <build source branch or tag name>/assets
-
-domain="https://mayflower.digital.mass.gov"
-assetsPath='assets'
-
-# Set url.domain and url.assetsPath
-writeAssetsPathConfig "$domain" "$assetsPath"
-
 # 5. Build pattern to generate prod static assets
-buildMayflower
+buildMayflower "https://mayflower.digital.mass.gov"
 
 # 6. Copy built assets in /public into new tmp directory
 # Make temp directory to copy public assets