Merge pull request #38 from githubtraining/rename-branch

rename default branch in responses

Author: hectorsector

README.md

@@ -14,9 +14,9 @@ For more information on the goals of this course, check out the [`course-details
 
 ## Contribute
 
-See something we could improve? Check out the contributing guide in the [community contributors repository](https://github.com/githubtraining/community-contributors/blob/master/CONTRIBUTING.md) for more information on the types of contributions we :heart: and instructions.
+See something we could improve? Check out the contributing guide in the [community contributors repository](https://github.com/githubtraining/community-contributors/blob/main/CONTRIBUTING.md) for more information on the types of contributions we :heart: and instructions.
 
-We :heart: our community and take great care to ensure it is fun, safe and rewarding. Please review our [Code of Conduct](https://github.com/githubtraining/community-contributors/blob/master/CODE_OF_CONDUCT.md) for community expectations and guidelines for reporting concerns.
+We :heart: our community and take great care to ensure it is fun, safe and rewarding. Please review our [Code of Conduct](https://github.com/githubtraining/community-contributors/blob/main/CODE_OF_CONDUCT.md) for community expectations and guidelines for reporting concerns.
 
 ## License
 

config.yml

@@ -13,7 +13,7 @@ template:
 
 # Before
 before:
-  # Repository must have a master branch with the working code, and 4 other branches:
+  # Repository must have a main branch with the working code, and 4 other branches:
     # staging-workflow: with the workflow file stub for staging from label
     # aws-configuration: with blank/stub files for `aws-config.yml` and `sam-template.yml`
     # production-deployment-workflow: with the workflow file stub for production deploy from merge
@@ -135,7 +135,7 @@ steps:
       right: closed
     - left: '%payload.pull_request.merged%'
 
-    # we reprotect master for the next PR
+    # we reprotect main for the next PR
   - type: updateBranchProtection
 
 # PART 2: AWS CONFIGURATION
@@ -194,11 +194,11 @@ steps:
   # we merge
   - type: mergeBranch
     head: aws-configuration
-    base: master
+    base: main
 
-  # merge master into staging-test so staging-test has the appropriate updates
+  # merge main into staging-test so staging-test has the appropriate updates
   - type: mergeBranch
-    head: master
+    head: main
     base: staging-test
 
   # we must prepare next pr now so we can point to it. We ask the user to test this action by adding a label
@@ -252,7 +252,24 @@ steps:
   actions: 
 
   # We validate
-  #- type: gate
+  - type: getFileContents
+    action_id: fileContents
+    filename: '.github/workflows/deploy-prod.yml'
+    required: false
+
+    # We validate that trigger is correct
+  - type: gate
+    every: true
+    gates:
+    - left: '%payload.pull_request.title%'
+      operator: ===
+      right: Production deployment workflow
+    - left: '%actions.fileContents%'
+    else:
+    - type: respond
+      with: 0Xe_unexpected.md
+      data:
+        expected: commit the file `.github/workflows/deploy-prod.yml` on a pull request titled "Production deployment workflow"
 
 # Step 10: Choose the environment for AWS
 
@@ -263,7 +280,7 @@ steps:
   # event: commit, user writes the environment
 
 - title: Complete the deployment to production workflow
-  description: Commit the steps to the production workflow that allow you to deploy on merge to master.
+  description: Commit the steps to the production workflow that allow you to deploy on merge to main.
   event: pull_request
   link: '{{ repoUrl }}/pull/3'
   actions:
@@ -298,7 +315,7 @@ steps:
 # We remove branch protections 
   - type: removeBranchProtection 
 
-# We tell the user to merge, and that their merge will bring the action into `master`, and will also create a deployment into production
+# We tell the user to merge, and that their merge will bring the action into `main`, and will also create a deployment into production
   - type: respond
     with: 12_merge.md
 

responses/01_label-trigger.md

@@ -2,7 +2,7 @@
 
 We'll learn how to create a workflow that enables Continuous Delivery. You'll:
 - create a workflow to deploy to staging based on a label
-- create a workflow to deploy to production based on merging to master
+- create a workflow to deploy to production based on merging to main
 
 Before you start, you should be familiar with GitHub and Continuous Integration. If you aren't sure where to start, you may want to check out these two Learning Lab courses:
 

responses/03_workflow-steps.md

@@ -58,7 +58,7 @@ jobs:
         run: |
           npm install
           npm run build
-      - uses: actions/upload-artifact@master
+      - uses: actions/upload-artifact@main
         with:
           name: webpack artifacts
           path: public/
@@ -72,7 +72,7 @@ jobs:
       - uses: actions/checkout@v1
 
       - name: Download built artifact
-        uses: actions/download-artifact@master
+        uses: actions/download-artifact@main
         with:
           name: webpack artifacts
           path: public

responses/09_merge-trigger.md

@@ -2,19 +2,19 @@
 
 Deployments to production can be manual (like through a Chat Ops command), or automated (if, say, we trust our pull request review process and we've followed continuous integration practices).
 
-We'll trigger a deployment to the production environment whenever something is committed to master. Our master branch is protected, so the only way for commits to appear on master is for a pull request to have been created and gone through the proper review process and merged.
+We'll trigger a deployment to the production environment whenever something is committed to main. Our main branch is protected, so the only way for commits to appear on main is for a pull request to have been created and gone through the proper review process and merged.
 
 ## Step 8: Write the production deployment trigger
 
-Let's create a new workflow that deals specifically with commits to master and handles deployments to prod.
+Let's create a new workflow that deals specifically with commits to main and handles deployments to prod.
 
-### :keyboard: Activity: Write the production deployment trigger on merge to master
+### :keyboard: Activity: Write the production deployment trigger on merge to main
 
 1. Edit the `deploy-prod.yml` file on this branch, or [use this quick link]({{ repoUrl }}/edit/production-deployment-workflow/.github/CHANGETHIS/deploy-prod.yml?) _(We recommend opening the quick link in another tab)_
 2. Rename the file in this pull request to `.github/workflows/deploy-prod.yml`
 3. Add a `push` trigger
 4. Add `branches` inside the push block
-5. Add `- master` inside the branches block
+5. Add `- main` inside the branches block
 6. Commit your changes to this branch
 
 The file should look like this when you're finished:
@@ -25,5 +25,5 @@ name: Production deployment
 on: 
   push:
     branches:
-      - master
+      - main
 ```

responses/10_deploy-prod.md

@@ -1,4 +1,4 @@
-Great! The syntax you used tells GitHub Actions to only run that workflow when a commit is made to the master branch. 
+Great! The syntax you used tells GitHub Actions to only run that workflow when a commit is made to the main branch. 
 
 # Deploying to production
 
@@ -10,7 +10,7 @@ In our case, we can match our production environment to be exactly like our stag
 
 ## Step 9: Complete the deployment to production workflow
 
-### :keyboard: Commit the steps to the production workflow that allow you to deploy on merge to master
+### :keyboard: Commit the steps to the production workflow that allow you to deploy on merge to main
 
 1. Edit the `deploy-prod.yml` file on this branch, or [use this quick link]({{ repoUrl }}/edit/production-deployment-workflow/.github/workflows/deploy-prod.yml?) _(We recommend opening the quick link in another tab)_
 2. Add a `build` and `deploy` job to the workflow
@@ -23,7 +23,7 @@ name: Production deployment
 on: 
   push:
     branches:
-      - master
+      - main
 
 jobs:
   build:
@@ -35,7 +35,7 @@ jobs:
         run: |
           npm install
           npm run build
-      - uses: actions/upload-artifact@master
+      - uses: actions/upload-artifact@main
         with:
           name: webpack artifacts
           path: public/
@@ -49,7 +49,7 @@ jobs:
       - uses: actions/checkout@v1
 
       - name: Download built artifact
-        uses: actions/download-artifact@master
+        uses: actions/download-artifact@main
         with:
           name: webpack artifacts
           path: public

responses/11_workflow-steps.md

@@ -23,7 +23,7 @@ All of this happens automatically once a pull request is merged!
         uses: actions/checkout@v1
 
       - name: Download built artifact
-        uses: actions/download-artifact@master
+        uses: actions/download-artifact@main
         with:
           name: webpack artifacts
           path: public
@@ -44,7 +44,7 @@ name: Production deployment
 on: 
   push:
     branches:
-      - master
+      - main
 
 jobs:
   build:
@@ -56,7 +56,7 @@ jobs:
         run: |
           npm install
           npm run build
-      - uses: actions/upload-artifact@master
+      - uses: actions/upload-artifact@main
         with:
           name: webpack artifacts
           path: public/
@@ -70,7 +70,7 @@ jobs:
       - uses: actions/checkout@v1
 
       - name: Download built artifact
-        uses: actions/download-artifact@master
+        uses: actions/download-artifact@main
         with:
           name: webpack artifacts
           path: public
@@ -90,7 +90,7 @@ jobs:
         uses: actions/checkout@v1
 
       - name: Download built artifact
-        uses: actions/download-artifact@master
+        uses: actions/download-artifact@main
         with:
           name: webpack artifacts
           path: public

responses/12_congratulations.md

@@ -2,6 +2,10 @@
 
 Now, we just have to wait for the deployment to occur, and for the package to be published to GitHub Packages. When it's completed, you should be able to see it in the [Packages]({{ repoUrl }}/packages) section of your repository. You can get the deployment URL in the [Actions]({{ repoUrl }}/actions) log, just like the staging URL.
 
+:bangbang: Remember to destroy or disable the AWS services created during this course if you'd like to ensure they don't consume resources accidentally. As a reminder, the following resources were created on your AWS account:
+- IAM user
+- S3 bucket
+
 ![celebrate](https://octodex.github.com/images/jetpacktocat.png)
 
 This course is now complete! I'll stop responding but the fun doesn't have to stop here.