From e6460980137bcfb9c3ba7673b2f3b290cfeef8a2 Mon Sep 17 00:00:00 2001 From: Robbie Wagner Date: Wed, 4 Dec 2024 10:06:28 -0500 Subject: [PATCH 1/7] Start updating deploy docs --- tests/dummy/app/templates/docs/deploying.md | 47 ++------------------- tests/dummy/app/templates/docs/patterns.md | 2 +- 2 files changed, 5 insertions(+), 44 deletions(-) diff --git a/tests/dummy/app/templates/docs/deploying.md b/tests/dummy/app/templates/docs/deploying.md index 867e745e2..b92512d30 100644 --- a/tests/dummy/app/templates/docs/deploying.md +++ b/tests/dummy/app/templates/docs/deploying.md @@ -52,58 +52,19 @@ 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. This setup can be used for GitHub Actions, which is currently the preferred, built-in CI used by Ember blueprints. -### Generate a deploy key - -The first step you'll need to take is to generate a _deploy key_. This is a special SSH key that will only have write access to a single git repository: the one for your addon. - -To generate the public/private key pair on macOS or Linux, you'll use the [`ssh-keygen`](https://www.freebsd.org/cgi/man.cgi?query=ssh-keygen&sektion=1&manpath=OpenBSD+3.9) command line tool. On Windows, you can use [PuTTYGen](https://www.ssh.com/ssh/putty/windows/puttygen) instead. - -```sh -ssh-keygen -t rsa -m PEM -b 4096 -N '' -f deploy_key -``` - -This will produce two files in your current directory: `deploy_key` (the private key) and `deploy_key.pub` (the public key). **Do not commit these files to your repository.** - -### Configure the public key with GitHub - -On GitHub, open the page for your repo and navigate to _Settings_ -> _Deploy keys_ (or just directly visit https://github.com/**[user]**/**[repo]**/settings/keys) and click "Add 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 - -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. - -```sh -travis env set -- DEPLOY_KEY "$(cat deploy_key)" -``` - -### 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`: +- Create a new file at `.github/workflows/addon-docs.yml` +- Paste in 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 ``` -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 -``` ## Customizing deploys diff --git a/tests/dummy/app/templates/docs/patterns.md b/tests/dummy/app/templates/docs/patterns.md index 99529dc62..c35532ca8 100644 --- a/tests/dummy/app/templates/docs/patterns.md +++ b/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 deploy guides for more information about deploys. From 405bdf665c5971d0de2f615a9f301cd04e6e6b94 Mon Sep 17 00:00:00 2001 From: Robbie Wagner Date: Wed, 4 Dec 2024 10:17:53 -0500 Subject: [PATCH 2/7] Update index.js --- blueprints/ember-cli-addon-docs/index.js | 1 - 1 file changed, 1 deletion(-) diff --git a/blueprints/ember-cli-addon-docs/index.js b/blueprints/ember-cli-addon-docs/index.js index b2f40b658..6a2fffd74 100644 --- a/blueprints/ember-cli-addon-docs/index.js +++ b/blueprints/ember-cli-addon-docs/index.js @@ -18,7 +18,6 @@ module.exports = { 'ember-cli-deploy', 'ember-cli-deploy-build', 'ember-cli-deploy-git', - 'ember-cli-deploy-git-ci', ], }); }, From 45f558b1425ed890aed6051f8a2ae673d3abda06 Mon Sep 17 00:00:00 2001 From: Robbie Wagner Date: Thu, 5 Dec 2024 12:11:18 -0500 Subject: [PATCH 3/7] Revert "Start updating deploy docs" This reverts commit e6460980137bcfb9c3ba7673b2f3b290cfeef8a2. --- tests/dummy/app/templates/docs/deploying.md | 47 +++++++++++++++++++-- tests/dummy/app/templates/docs/patterns.md | 2 +- 2 files changed, 44 insertions(+), 5 deletions(-) diff --git a/tests/dummy/app/templates/docs/deploying.md b/tests/dummy/app/templates/docs/deploying.md index b92512d30..867e745e2 100644 --- a/tests/dummy/app/templates/docs/deploying.md +++ b/tests/dummy/app/templates/docs/deploying.md @@ -52,19 +52,58 @@ 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 `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. +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. ## Automating deploys -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. This setup can be used for GitHub Actions, which is currently the preferred, built-in CI used by Ember blueprints. +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. -- Create a new file at `.github/workflows/addon-docs.yml` -- Paste in the following contents: +### Generate a deploy key + +The first step you'll need to take is to generate a _deploy key_. This is a special SSH key that will only have write access to a single git repository: the one for your addon. + +To generate the public/private key pair on macOS or Linux, you'll use the [`ssh-keygen`](https://www.freebsd.org/cgi/man.cgi?query=ssh-keygen&sektion=1&manpath=OpenBSD+3.9) command line tool. On Windows, you can use [PuTTYGen](https://www.ssh.com/ssh/putty/windows/puttygen) instead. + +```sh +ssh-keygen -t rsa -m PEM -b 4096 -N '' -f deploy_key +``` + +This will produce two files in your current directory: `deploy_key` (the private key) and `deploy_key.pub` (the public key). **Do not commit these files to your repository.** + +### Configure the public key with GitHub + +On GitHub, open the page for your repo and navigate to _Settings_ -> _Deploy keys_ (or just directly visit https://github.com/**[user]**/**[repo]**/settings/keys) and click "Add 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 + +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. + +```sh +travis env set -- DEPLOY_KEY "$(cat deploy_key)" +``` + +### 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`: ```yml +after_success: + - if [[ ($TRAVIS_BRANCH == master || -n $TRAVIS_TAG) && $EMBER_TRY_SCENARIO == ember-default ]]; then + node_modules/.bin/ember deploy production; + fi ``` +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 +``` ## Customizing deploys diff --git a/tests/dummy/app/templates/docs/patterns.md b/tests/dummy/app/templates/docs/patterns.md index c35532ca8..99529dc62 100644 --- a/tests/dummy/app/templates/docs/patterns.md +++ b/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 `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`. +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`. See the next section on deploy guides for more information about deploys. From 9881121f5cf1e5c8b19cef6f969718c2037f32fa Mon Sep 17 00:00:00 2001 From: Robbie Wagner Date: Thu, 5 Dec 2024 12:11:21 -0500 Subject: [PATCH 4/7] Revert "Update index.js" This reverts commit 405bdf665c5971d0de2f615a9f301cd04e6e6b94. --- blueprints/ember-cli-addon-docs/index.js | 1 + 1 file changed, 1 insertion(+) diff --git a/blueprints/ember-cli-addon-docs/index.js b/blueprints/ember-cli-addon-docs/index.js index 6a2fffd74..b2f40b658 100644 --- a/blueprints/ember-cli-addon-docs/index.js +++ b/blueprints/ember-cli-addon-docs/index.js @@ -18,6 +18,7 @@ module.exports = { 'ember-cli-deploy', 'ember-cli-deploy-build', 'ember-cli-deploy-git', + 'ember-cli-deploy-git-ci', ], }); }, From aa8ffd131b0fe8138da9c935a3eb1554448871a8 Mon Sep 17 00:00:00 2001 From: Robbie Wagner Date: Thu, 5 Dec 2024 12:16:44 -0500 Subject: [PATCH 5/7] Tweak deploy config --- .github/workflows/ci-cd.yml | 23 ++++++++--------------- config/deploy.js | 2 +- package.json | 1 - 3 files changed, 9 insertions(+), 17 deletions(-) diff --git a/.github/workflows/ci-cd.yml b/.github/workflows/ci-cd.yml index cd4f4a6b9..2e501f3f4 100644 --- a/.github/workflows/ci-cd.yml +++ b/.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' 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 diff --git a/config/deploy.js b/config/deploy.js index d5230b73c..765696a59 100644 --- a/config/deploy.js +++ b/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', }, }; diff --git a/package.json b/package.json index d2f1ce235..6ba9196bd 100644 --- a/package.json +++ b/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\"", From 6cfc3a16d9685230de1c944ab2dd317b618531f7 Mon Sep 17 00:00:00 2001 From: Robbie Wagner Date: Thu, 5 Dec 2024 12:38:02 -0500 Subject: [PATCH 6/7] Make primary branch main, update deploy docs for GitHub Actions --- lib/config.js | 2 +- tests/dummy/app/templates/docs/deploying.md | 69 ++++++++++++++------- tests/dummy/app/templates/docs/patterns.md | 2 +- tests/dummy/config/addon-docs.js | 6 +- 4 files changed, 53 insertions(+), 26 deletions(-) diff --git a/lib/config.js b/lib/config.js index 9b16612d4..51b01111e 100644 --- a/lib/config.js +++ b/lib/config.js @@ -11,7 +11,7 @@ module.exports = class AddonDocsConfig { } getPrimaryBranch() { - return 'master'; + return 'main'; } getRootURL() { diff --git a/tests/dummy/app/templates/docs/deploying.md b/tests/dummy/app/templates/docs/deploying.md index 867e745e2..904b4c31a 100644 --- a/tests/dummy/app/templates/docs/deploying.md +++ b/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 https://github.com/**[user]**/**[repo]**/settings/secrets/actions) 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, + }, }; // ... ``` diff --git a/tests/dummy/app/templates/docs/patterns.md b/tests/dummy/app/templates/docs/patterns.md index 99529dc62..c35532ca8 100644 --- a/tests/dummy/app/templates/docs/patterns.md +++ b/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 deploy guides for more information about deploys. diff --git a/tests/dummy/config/addon-docs.js b/tests/dummy/config/addon-docs.js index edc54713f..67fef9dbb 100644 --- a/tests/dummy/config/addon-docs.js +++ b/tests/dummy/config/addon-docs.js @@ -3,4 +3,8 @@ const AddonDocsConfig = require('../../../lib/config'); -module.exports = class extends AddonDocsConfig {}; +module.exports = class extends AddonDocsConfig { + getPrimaryBranch() { + return 'master'; + } +}; From 979015c9b99c0554b64892f922b8c9f0c23da549 Mon Sep 17 00:00:00 2001 From: Robbie Wagner Date: Thu, 5 Dec 2024 14:34:15 -0500 Subject: [PATCH 7/7] Switch remaining master references to main --- .github/workflows/ci-cd.yml | 2 +- .../acceptance/sandbox/api/components-test.js | 4 ++-- tests/acceptance/version-selector-test.js | 24 +++++++++---------- tests/dummy/app/templates/docs/quickstart.md | 4 ++-- tests/dummy/config/addon-docs.js | 6 +---- tests/dummy/mirage/config.js | 6 ++--- 6 files changed, 21 insertions(+), 25 deletions(-) diff --git a/.github/workflows/ci-cd.yml b/.github/workflows/ci-cd.yml index 2e501f3f4..03d24710a 100644 --- a/.github/workflows/ci-cd.yml +++ b/.github/workflows/ci-cd.yml @@ -127,7 +127,7 @@ jobs: 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@v4 diff --git a/tests/acceptance/sandbox/api/components-test.js b/tests/acceptance/sandbox/api/components-test.js index 796eef4d3..f88fe74fe 100644 --- a/tests/acceptance/sandbox/api/components-test.js +++ b/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', ); }); }); diff --git a/tests/acceptance/version-selector-test.js b/tests/acceptance/version-selector-test.js index 7f6acd5d9..f71a38c90 100644 --- a/tests/acceptance/version-selector-test.js +++ b/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'); }); }); diff --git a/tests/dummy/app/templates/docs/quickstart.md b/tests/dummy/app/templates/docs/quickstart.md index ac748031e..beb103e81 100644 --- a/tests/dummy/app/templates/docs/quickstart.md +++ b/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 an autodocumented YUIDoc component 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 an autodocumented YUIDoc component 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 `` component. -Check out the sandbox 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 the sandbox 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 diff --git a/tests/dummy/config/addon-docs.js b/tests/dummy/config/addon-docs.js index 67fef9dbb..edc54713f 100644 --- a/tests/dummy/config/addon-docs.js +++ b/tests/dummy/config/addon-docs.js @@ -3,8 +3,4 @@ const AddonDocsConfig = require('../../../lib/config'); -module.exports = class extends AddonDocsConfig { - getPrimaryBranch() { - return 'master'; - } -}; +module.exports = class extends AddonDocsConfig {}; diff --git a/tests/dummy/mirage/config.js b/tests/dummy/mirage/config.js index 472a7a4dd..0c324ffcc 100644 --- a/tests/dummy/mirage/config.js +++ b/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', }, }; });