Switch default primary branch to main, update docs from Travis to G…

…itHub Actions (#1617)

* Start updating deploy docs

* Update index.js

* Revert "Start updating deploy docs"

This reverts commit e646098.

* Revert "Update index.js"

This reverts commit 405bdf6.

* Tweak deploy config

* Make primary branch main, update deploy docs for GitHub Actions

* Switch remaining master references to main

.github/workflows/ci-cd.yml

@@ -122,32 +122,25 @@ jobs:
   deploy-app:
     name: Deploy app
     needs: [lint, test-addon-floating, test-addon-locked, test-compatibility]
+    env:
+      DEPLOY_KEY: ${{ secrets.DEPLOY_KEY }}
     runs-on: ubuntu-latest
     timeout-minutes: 7
     # Only run on pushes to the default branch
-    if: github.event_name == 'push' && github.ref == 'refs/heads/master'
+    if: github.event_name == 'push' && github.ref == 'refs/heads/main'
     steps:
       - name: Check out a copy of the repo
-        uses: actions/checkout@v3
-
-      - name: Set up Git user
-        run: |
-          # Set up a Git user for committing
-          git config --global user.name "GitHub Actions"
-          git config --global user.email "actions@users.noreply.github.com"
-
-          # Copy the Git Auth from the local config
-          git config --global "http.https://github.com/.extraheader" \
-            "$(git config --local --get http.https://github.com/.extraheader)"
-
+        uses: actions/checkout@v4
+        with:
+          token: ${{ secrets.GITHUB_TOKEN }}
       - name: Use Node.js ${{ env.NODE_VERSION }}
-        uses: actions/setup-node@v3
+        uses: actions/setup-node@v4
         with:
           node-version: ${{ env.NODE_VERSION }}
           cache: pnpm
 
       - name: Install dependencies
-        run: pnpm i --frozen-lockfile
+        run: pnpm install --no-lockfile
 
       - name: Deploy
-        run: pnpm deploy
+        run: pnpm ember deploy production

config/deploy.js

@@ -4,7 +4,7 @@ module.exports = function (deployTarget) {
   let ENV = {
     build: {},
     git: {
-      repo: 'https://github.com/ember-learn/ember-cli-addon-docs.git',
+      repo: 'git@github.com:ember-learn/ember-cli-addon-docs.git',
     },
   };
 

lib/config.js

@@ -11,7 +11,7 @@ module.exports = class AddonDocsConfig {
   }
 
   getPrimaryBranch() {
-    return 'master';
+    return 'main';
   }
 
   getRootURL() {

package.json

@@ -15,7 +15,6 @@
   },
   "scripts": {
     "build": "ember build --environment=production",
-    "deploy": "ember deploy production",
     "lint": "concurrently \"npm:lint:*(!fix)\" --names \"lint:\"",
     "lint:css": "stylelint \"**/*.css\"",
     "lint:css:fix": "concurrently \"npm:lint:css -- --fix\"",

tests/acceptance/sandbox/api/components-test.js

@@ -37,7 +37,7 @@ module('Acceptance | Sandbox | API | components', function (hooks) {
 
     assert.strictEqual(
       editThisPageLinkHref,
-      'https://github.com/ember-learn/ember-cli-addon-docs/edit/master/tests/dummy/app/pods/sandbox/index/template.md',
+      'https://github.com/ember-learn/ember-cli-addon-docs/edit/main/tests/dummy/app/pods/sandbox/index/template.md',
     );
   });
 
@@ -61,7 +61,7 @@ module('Acceptance | Sandbox | API | components', function (hooks) {
 
       assert.strictEqual(
         editThisPageLinkHref,
-        'https://github.com/ember-learn/ember-cli-addon-docs/edit/master/packages/foo-bar/tests/dummy/app/pods/sandbox/index/template.md',
+        'https://github.com/ember-learn/ember-cli-addon-docs/edit/main/packages/foo-bar/tests/dummy/app/pods/sandbox/index/template.md',
       );
     });
   });

tests/acceptance/version-selector-test.js

@@ -49,11 +49,11 @@ module('Acceptance | Version selector test', function (hooks) {
         path: '',
         name: 'Latest',
       },
-      master: {
+      main: {
         sha: '53b73465d31925f26fd1f77881aefcaccce2915a',
         tag: null,
-        path: 'master',
-        name: 'master',
+        path: 'main',
+        name: 'main',
       },
       'v0.2.x': {
         sha: 'aca26720d930843dd084b508fce75b158ff0386e',
@@ -90,7 +90,7 @@ module('Acceptance | Version selector test', function (hooks) {
 
     assert
       .dom('[data-test-id="version"]:nth-child(2)')
-      .includesText('master', 'master is rendered secon');
+      .includesText('main', 'main is rendered second');
     assert.dom('[data-test-id="version"]:nth-child(2)').includesText('53b73');
 
     assert
@@ -113,11 +113,11 @@ module('Acceptance | Version selector test', function (hooks) {
         path: '',
         name: 'Latest',
       },
-      master: {
+      main: {
         sha: '53b73465d31925f26fd1f77881aefcaccce2915a',
         tag: null,
-        path: 'master',
-        name: 'master',
+        path: 'main',
+        name: 'main',
       },
       'v0.1.0': {
         sha: 'd752437850bc9833ea3e354095b501473b0420ae',
@@ -145,7 +145,7 @@ module('Acceptance | Version selector test', function (hooks) {
       .includesText('Latest', 'latest is rendered on second open');
     assert
       .dom('[data-test-id="version"]:nth-child(2)')
-      .includesText('master', 'master is rendered on second open');
+      .includesText('main', 'main is rendered on second open');
   });
 
   module('with a custom primary branch configured', function (hooks) {
@@ -167,11 +167,11 @@ module('Acceptance | Version selector test', function (hooks) {
           path: '',
           name: 'Latest',
         },
-        master: {
+        main: {
           sha: '53b73465d31925f26fd1f77881aefcaccce2915a',
           tag: null,
-          path: 'master',
-          name: 'master',
+          path: 'main',
+          name: 'main',
         },
         develop: {
           sha: '53b73465d31925f26fd1f77881aefcaccce2915a',
@@ -201,7 +201,7 @@ module('Acceptance | Version selector test', function (hooks) {
 
       assert
         .dom('[data-test-id="version"]:nth-child(3)')
-        .includesText('master', 'other branches are rendered last');
+        .includesText('main', 'other branches are rendered last');
       assert.dom('[data-test-id="version"]:nth-child(3)').includesText('53b73');
     });
   });

tests/dummy/app/templates/docs/deploying.md

@@ -52,11 +52,11 @@ Note that this only applies to non-prerelease tags, so `v1.2.3` would update the
 
 When you deploy from a commit at the head of a branch that _doesn't_ have a tag associated with it, the compiled app will land in a folder named after that branch, as in our "getting started" example above. Unlike tag deploys, branch deploys will never automatically update the root app.
 
-The main use case for branch deploys is tracking development work since your last stable release. If you run `ember deploy` after successful builds on `master`, you'll always have documentation available for the bleeding edge of your addon's features. Since branch deploys don't update the root, though, developers looking at your docs will still hit your most recent stable tag by default, so there won't be any confusion about things that have drifted since the last release.
+The main use case for branch deploys is tracking development work since your last stable release. If you run `ember deploy` after successful builds on `main`, you'll always have documentation available for the bleeding edge of your addon's features. Since branch deploys don't update the root, though, developers looking at your docs will still hit your most recent stable tag by default, so there won't be any confusion about things that have drifted since the last release.
 
 ## Automating deploys
 
-While you _can_ just run `ember deploy production` yourself after every commit to `master` and each new release of your addon, you can simplify life a bit by automating the process as part of your CI setup. The process described here details the configuration for [Travis CI](https://travis-ci.org/), which Ember addons are configured to work with out of the box, but the setup should be very similar for other CI providers.
+While you _can_ just run `ember deploy production` yourself after every commit to `main` and each new release of your addon, you can simplify life a bit by automating the process as part of your CI setup. The process described here details the configuration for GitHub Actions, which Ember addons are configured to work with out of the box, but the setup should be very similar for other CI providers.
 
 ### Generate a deploy key
 
@@ -76,41 +76,64 @@ On GitHub, open the page for your repo and navigate to _Settings_ -> _Deploy key
 
 Enter a name for your key and then paste the contents of your public key (`deploy_key.pub`) into the big textarea. Make sure you check the **Allow write access** box, then click "Add key" and you're all set.
 
-### Configure the private key with Travis
+### Configure the private key with GitHub Actions
 
-Now that GitHub knows that this public key is allowed to push commits to your repo, we need to set up Travis to use the corresponding private key. Because the keyfile contains newlines, the easiest way to do this is using the [Travis CLI](https://github.com/travis-ci/travis.rb#installation) tool.
+Now that GitHub knows that this public key is allowed to push commits to your repo, we need to set up GitHub Actions to use the corresponding private key.
+
+You can copy your private key by running the following:
 
 ```sh
-travis env set -- DEPLOY_KEY "$(cat deploy_key)"
+cat deploy_key | pbcopy
 ```
 
+Then you will need to go to the page for your repo and navigate to _Settings_ -> _Secrets and variables_ -> _Actions_ (or just directly visit <u>https://github.com/**[user]**/**[repo]**/settings/secrets/actions)</u> and click "New repository secret". The name should be `DEPLOY_KEY` and the value should be the private key you just copied.
+
 ### Deploy after successful builds
 
-All that's left now is to set up Travis to run your deploys for you. The simplest way to do this is to add this `after_success` script to the end of your `.travis.yml`:
+All that's left now is to set up GitHub Actions to run your deploys for you. The simplest way to do this is to create a new file under `.github/workflows/addon-docs.yml` with the following contents:
 
 ```yml
-after_success:
-  - if [[ ($TRAVIS_BRANCH == master || -n $TRAVIS_TAG) && $EMBER_TRY_SCENARIO == ember-default ]]; then
-    node_modules/.bin/ember deploy production;
-    fi
+name: Publish Addon Docs
+
+on:
+  push:
+    branches:
+      - main
+      - master
+    tags:
+      - "**"
+jobs:
+  build:
+    env:
+      DEPLOY_KEY: ${{ secrets.DEPLOY_KEY }}
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+        with:
+          token: ${{ secrets.GITHUB_TOKEN }}
+      - uses: pnpm/action-setup@v4
+        with:
+          version: 9
+      - uses: actions/setup-node@v4
+        with:
+          node-version: 18
+          cache: pnpm
+      - name: Install Dependencies
+        run: pnpm install --no-lockfile
+      - name: Deploy Docs
+        run: |
+          cd test-app
+          pnpm ember deploy production
 ```
 
-Alternatively, if you're using Travis's [build stages system](https://docs.travis-ci.com/user/build-stages/), you can set up the deploy as a conditional stage at the end of your build:
-
-```yml
-stages:
-  # ...your other build stages...
-  - name: deploy
-    if: (branch = master or tag is present) and type = push
-    script: node_modules/.bin/ember deploy production
-```
+This assumes you have a v2 addon and your addon docs are in the `test-app` folder, but if your addon docs are in a different location, you can change `test-app` to whatever that folder is and `cd` into it.
 
 ## Customizing deploys
 
 When you install AddonDocs, a `config/addon-docs.js` file will automatically be created for you that looks something like this:
 
 ```js
-const AddonDocsConfig = require('ember-cli-addon-docs/lib/config');
+const AddonDocsConfig = require("ember-cli-addon-docs/lib/config");
 
 module.exports = class extends AddonDocsConfig {
   // ...
@@ -145,7 +168,7 @@ If instead, however, you want to [set up a CNAME for your project](https://help.
 
 ### `getPrimaryBranch()`
 
-This method determines what AddonDocs considers to be your primary branch, which is where links such as "edit this page" will point. By default, this branch is `master`, but you can override this method to choose a different branch instead, e.g. `develop`.
+This method determines what AddonDocs considers to be your primary branch, which is where links such as "edit this page" will point. By default, this branch is `main`, but you can override this method to choose a different branch instead, e.g. `develop`.
 
 ## Removing a deployed version
 
@@ -178,8 +201,8 @@ If you wish to disable ember-cli-addon-docs' built-in deployment plugins altoget
 // ...
 ENV.pipeline = {
   disabled: {
-    'ember-cli-addon-docs': true
-  }
+    "ember-cli-addon-docs": true,
+  },
 };
 // ...
 ```

tests/dummy/app/templates/docs/patterns.md

@@ -62,7 +62,7 @@ AddonDocs provides versioned guides out of the box. You can see the version sele
 
 If you look at the [`gh-pages`](https://github.com/ember-learn/ember-cli-addon-docs/tree/gh-pages) branch you'll see that this is where versioned builds of your docs app are stored. Versions are created at deploy time and AddonDocs manages this branch of your repository for you.
 
-New versions are created when a new tag is released. There is also a `master` version updated on every deployed commit, and a `Latest` alias that points to the most recent tag, unless it is force-updated to point to `master`.
+New versions are created when a new tag is released. There is also a `main` version updated on every deployed commit, and a `Latest` alias that points to the most recent tag, unless it is force-updated to point to `main`.
 
 See the next section on <DocsLink @route="docs.deploying">deploy guides</DocsLink> for more information about deploys.
 

tests/dummy/app/templates/docs/quickstart.md

@@ -16,7 +16,7 @@ For both classic and native classes, install the [YUIDoc](http://yui.github.io/y
 ember install ember-cli-addon-docs-yuidoc
 ```
 
-You can see an example of <DocsLink @route="sandbox.api.item" @model="components/yuidoc-component">an autodocumented YUIDoc component</DocsLink> in the sandbox, and view its source [on GitHub](https://github.com/ember-learn/ember-cli-addon-docs/blob/master/sandbox/app/components/yuidoc-component.js).
+You can see an example of <DocsLink @route="sandbox.api.item" @model="components/yuidoc-component">an autodocumented YUIDoc component</DocsLink> in the sandbox, and view its source [on GitHub](https://github.com/ember-learn/ember-cli-addon-docs/blob/main/sandbox/app/components/yuidoc-component.js).
 
 ## 3. Add the docs routes
 
@@ -133,7 +133,7 @@ Remember, the dummy site is a full Ember application and these components are ju
 
 As you document the public objects in your addon, they'll automatically show up in the left-hand navigation of your `docs` route under the "API REFERENCE" section, assuming you added the `<DocsViewer/>` component.
 
-Check out <DocsLink @route="sandbox">the sandbox</DocsLink> for an example addon with autogenerated API docs on the side. You can also take a look [at the code on GitHub](https://github.com/ember-learn/ember-cli-addon-docs/tree/master/sandbox) to see how these objects were documented.
+Check out <DocsLink @route="sandbox">the sandbox</DocsLink> for an example addon with autogenerated API docs on the side. You can also take a look [at the code on GitHub](https://github.com/ember-learn/ember-cli-addon-docs/tree/main/sandbox) to see how these objects were documented.
 
 ## 9. Add a 404 route
 

tests/dummy/mirage/config.js

@@ -14,11 +14,11 @@ export default function (config) {
             path: '',
             name: '-latest',
           },
-          master: {
+          main: {
             sha: '12345',
             tag: null,
-            path: 'master',
-            name: 'master',
+            path: 'main',
+            name: 'main',
           },
         };
       });