You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardexpand all lines: tests/dummy/app/templates/docs/deploying.md
+46-23
Original file line number
Diff line number
Diff line change
@@ -52,11 +52,11 @@ Note that this only applies to non-prerelease tags, so `v1.2.3` would update the
52
52
53
53
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.
54
54
55
-
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.
55
+
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.
56
56
57
57
## Automating deploys
58
58
59
-
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.
59
+
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.
60
60
61
61
### Generate a deploy key
62
62
@@ -76,41 +76,64 @@ On GitHub, open the page for your repo and navigate to _Settings_ -> _Deploy key
76
76
77
77
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.
78
78
79
-
### Configure the private key with Travis
79
+
### Configure the private key with GitHub Actions
80
80
81
-
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.
81
+
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.
82
+
83
+
You can copy your private key by running the following:
82
84
83
85
```sh
84
-
travis env set -- DEPLOY_KEY "$(cat deploy_key)"
86
+
cat deploy_key| pbcopy
85
87
```
86
88
89
+
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.
90
+
87
91
### Deploy after successful builds
88
92
89
-
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`:
93
+
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:
90
94
91
95
```yml
92
-
after_success:
93
-
- if [[ ($TRAVIS_BRANCH == master || -n $TRAVIS_TAG) && $EMBER_TRY_SCENARIO == ember-default ]]; then
94
-
node_modules/.bin/ember deploy production;
95
-
fi
96
+
name: Publish Addon Docs
97
+
98
+
on:
99
+
push:
100
+
branches:
101
+
- main
102
+
- master
103
+
tags:
104
+
- "**"
105
+
jobs:
106
+
build:
107
+
env:
108
+
DEPLOY_KEY: ${{ secrets.DEPLOY_KEY }}
109
+
runs-on: ubuntu-latest
110
+
steps:
111
+
- uses: actions/checkout@v4
112
+
with:
113
+
token: ${{ secrets.GITHUB_TOKEN }}
114
+
- uses: pnpm/action-setup@v4
115
+
with:
116
+
version: 9
117
+
- uses: actions/setup-node@v4
118
+
with:
119
+
node-version: 18
120
+
cache: pnpm
121
+
- name: Install Dependencies
122
+
run: pnpm install --no-lockfile
123
+
- name: Deploy Docs
124
+
run: |
125
+
cd test-app
126
+
pnpm ember deploy production
96
127
```
97
128
98
-
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:
99
-
100
-
```yml
101
-
stages:
102
-
# ...your other build stages...
103
-
- name: deploy
104
-
if: (branch = master or tag is present) and type = push
105
-
script: node_modules/.bin/ember deploy production
106
-
```
129
+
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.
107
130
108
131
## Customizing deploys
109
132
110
133
When you install AddonDocs, a `config/addon-docs.js` file will automatically be created for you that looks something like this:
@@ -145,7 +168,7 @@ If instead, however, you want to [set up a CNAME for your project](https://help.
145
168
146
169
### `getPrimaryBranch()`
147
170
148
-
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`.
171
+
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`.
149
172
150
173
## Removing a deployed version
151
174
@@ -178,8 +201,8 @@ If you wish to disable ember-cli-addon-docs' built-in deployment plugins altoget
Copy file name to clipboardexpand all lines: tests/dummy/app/templates/docs/patterns.md
+1-1
Original file line number
Diff line number
Diff line change
@@ -62,7 +62,7 @@ AddonDocs provides versioned guides out of the box. You can see the version sele
62
62
63
63
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.
64
64
65
-
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`.
65
+
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`.
66
66
67
67
See the next section on <DocsLink @route="docs.deploying">deploy guides</DocsLink> for more information about deploys.
Copy file name to clipboardexpand all lines: tests/dummy/app/templates/docs/quickstart.md
+2-2
Original file line number
Diff line number
Diff line change
@@ -16,7 +16,7 @@ For both classic and native classes, install the [YUIDoc](http://yui.github.io/y
16
16
ember install ember-cli-addon-docs-yuidoc
17
17
```
18
18
19
-
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).
19
+
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).
20
20
21
21
## 3. Add the docs routes
22
22
@@ -133,7 +133,7 @@ Remember, the dummy site is a full Ember application and these components are ju
133
133
134
134
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.
135
135
136
-
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.
136
+
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.
0 commit comments