From edec1a9eda95bcce84254fb3b6591dc9eb9796d2 Mon Sep 17 00:00:00 2001 From: Yangshun Tay Date: Tue, 26 Mar 2019 23:16:34 -0700 Subject: [PATCH] misc: s/Circle CI/CircleCI --- CHANGELOG.md | 18 +++++++++--------- docs/api-commands.md | 2 +- docs/getting-started-publishing.md | 16 ++++++++-------- ...30-How-I-Converted-Profilo-To-Docusaurus.md | 2 +- website-1.x/static/.circleci/config.yml | 4 ++-- .../version-1.0.11/api-commands.md | 2 +- .../getting-started-publishing.md | 14 +++++++------- .../getting-started-publishing.md | 12 ++++++------ .../getting-started-publishing.md | 12 ++++++------ .../version-1.0.15/api-commands.md | 2 +- .../getting-started-publishing.md | 12 ++++++------ .../version-1.1.0/api-commands.md | 2 +- .../getting-started-publishing.md | 12 ++++++------ .../version-1.2.0/api-commands.md | 2 +- .../getting-started-publishing.md | 12 ++++++------ .../version-1.2.1/api-commands.md | 2 +- .../getting-started-publishing.md | 14 +++++++------- .../version-1.5.1/api-commands.md | 2 +- .../getting-started-publishing.md | 12 ++++++------ .../getting-started-publishing.md | 16 ++++++++-------- .../getting-started-publishing.md | 16 ++++++++-------- 21 files changed, 93 insertions(+), 93 deletions(-) diff --git a/CHANGELOG.md b/CHANGELOG.md index aa94d9d495..ccd5a5b211 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -14,16 +14,16 @@ Thank you to the following contributors who helped with this release: - @zpao - @jeromesimeon -- @yangshun -- @bartanthonissen -- @YoshinoriN -- @marvinchin +- @yangshun +- @bartanthonissen +- @YoshinoriN +- @marvinchin - @sinchange - @githubsaturn -- @fiennyangeln +- @fiennyangeln - @ahtee - @endiliey -- @ael-mas +- @ael-mas - @natemago - @co16353sidak - @CPSTL @@ -34,7 +34,7 @@ Thank you to the following contributors who helped with this release: - Update code.facebook.com links to appropriate new destination ([#1224](https://github.com/facebook/Docusaurus/pull/1224)) - docs: showcase user accord-project ([#1225](https://github.com/facebook/Docusaurus/pull/1225)) - fix: change mainContainer padding to align with sidebars -- docs: mention about CNAME option in publishing docs ([#1227](https://github.com/facebook/Docusaurus/pull/1227)) +- docs: mention about CNAME option in publishing docs ([#1227](https://github.com/facebook/Docusaurus/pull/1227)) - docs: add ScanTrust to users ([#1228](https://github.com/facebook/Docusaurus/pull/1228)) - chore: upgrade husky to 1.3.1 ([#1229](https://github.com/facebook/Docusaurus/pull/1229)) - Remove more references to code.facebook.com ([#1231](https://github.com/facebook/Docusaurus/pull/1231)) @@ -42,7 +42,7 @@ Thank you to the following contributors who helped with this release: - fix: hovering algolia logo break its background color ([#1240](https://github.com/facebook/Docusaurus/pull/1240)) - docs: update CaptainDuckDuck to CapRover ([#1244](https://github.com/facebook/Docusaurus/pull/1244)) - chore: rename siteConfig.js to docusaurus.config.js ([#1245](https://github.com/facebook/Docusaurus/pull/1245)) -- fix: make referenced links work with code block tabs ([#1249](https://github.com/facebook/Docusaurus/pull/1249)) +- fix: make referenced links work with code block tabs ([#1249](https://github.com/facebook/Docusaurus/pull/1249)) - docs: showcase user Scalafmt ([#1250](https://github.com/facebook/Docusaurus/pull/1250)) - fix: wrong sidebar_label and title on versioned_docs ([#1265](https://github.com/facebook/Docusaurus/pull/1265)) - docs: update api-pages.md to document about overriding default styles ([#1266](https://github.com/facebook/Docusaurus/pull/1266)) @@ -878,7 +878,7 @@ N/A - [Add separate, on-page navigation sidebar option so that you can see links to local page topics](https://github.com/facebook/Docusaurus/commit/4ff2fe280ebd41c4b491936fdd4ae75b7805ed61), thanks @microbouji. - [You can now use a custom `appId` for your Algolia search](https://github.com/facebook/Docusaurus/commit/4ea8158c0cf2105b0fec767289fd722ebc6e3a92), thanks @atroncy. - [The header navigation now shows the active link clearly](https://github.com/facebook/Docusaurus/commit/48ee457ec98b728343196362d5d42c0dc3d1cff9), thanks @microbouji. -- [Replace Circle CI 1.0 publishing documentation with Circle CI 2.0](https://docusaurus.io/docs/en/publishing.html#using-circle-ci-20), thanks @ashleytqy. +- [Replace CircleCI 1.0 publishing documentation with CircleCI 2.0](https://docusaurus.io/docs/en/publishing.html#using-circle-ci-20), thanks @ashleytqy. ### Fixed/Changed diff --git a/docs/api-commands.md b/docs/api-commands.md index 3a43fb60ca..cf592fcf41 100644 --- a/docs/api-commands.md +++ b/docs/api-commands.md @@ -88,7 +88,7 @@ When no feature is specified, sets up a minimally configured example website in Alias: `publish-gh-pages` -[Builds](api-commands.md#docusaurus-build), then deploys the static website to GitHub Pages. This command is meant to be run during the deployment step in Circle CI, and therefore expects a few environment variables to be defined: +[Builds](api-commands.md#docusaurus-build), then deploys the static website to GitHub Pages. This command is meant to be run during the deployment step in CircleCI, and therefore expects a few environment variables to be defined: The following environment variables are generally set manually by the user in the CircleCI `config.yml` file. diff --git a/docs/getting-started-publishing.md b/docs/getting-started-publishing.md index 6c6ac59c25..9db0849f56 100644 --- a/docs/getting-started-publishing.md +++ b/docs/getting-started-publishing.md @@ -101,16 +101,16 @@ However, you can automate the publishing process with continuous integration (CI ## Automating Deployments Using Continuous Integration -Continuous integration (CI) services are typically used to perform routine tasks whenever new commits are checked in to source control. These tasks can be any combination of running unit tests and integration tests, automating builds, publishing packages to NPM, and yes, deploying changes to your website. All you need to do to automate deployment of your website is to invoke the `publish-gh-pages` script whenever your docs get updated. In the following section we'll be covering how to do just that using [Circle CI](https://circleci.com/), a popular continuous integration service provider. +Continuous integration (CI) services are typically used to perform routine tasks whenever new commits are checked in to source control. These tasks can be any combination of running unit tests and integration tests, automating builds, publishing packages to NPM, and yes, deploying changes to your website. All you need to do to automate deployment of your website is to invoke the `publish-gh-pages` script whenever your docs get updated. In the following section we'll be covering how to do just that using [CircleCI](https://circleci.com/), a popular continuous integration service provider. -### Using Circle CI 2.0 +### Using CircleCI 2.0 If you haven't done so already, you can [setup CircleCI](https://circleci.com/signup/) for your open source project. Afterwards, in order to enable automatic deployment of your site and documentation via CircleCI, just configure Circle to run the `publish-gh-pages` script as part of the deployment step. You can follow the steps below to get that setup. 1. Ensure the GitHub account that will be set as the `GIT_USER` has `write` access to the repository that contains the documentation, by checking `Settings | Collaborators & teams` in the repository. 1. Log into GitHub as the `GIT_USER`. 1. Go to https://github.com/settings/tokens for the `GIT_USER` and generate a new [personal access token](https://help.github.com/articles/creating-a-personal-access-token-for-the-command-line/), granting it full control of private repositories through the `repository` access scope. Store this token in a safe place, making sure to not share it with anyone. This token can be used to authenticate GitHub actions on your behalf in place of your GitHub password. -1. Open your Circle CI dashboard, and navigate to the Settings page for your repository, then select "Environment variables". The URL looks like https://circleci.com/gh/ORG/REPO/edit#env-vars, where "ORG/REPO" should be replaced with your own GitHub organization/repository. +1. Open your CircleCI dashboard, and navigate to the Settings page for your repository, then select "Environment variables". The URL looks like https://circleci.com/gh/ORG/REPO/edit#env-vars, where "ORG/REPO" should be replaced with your own GitHub organization/repository. 1. Create a new environment variable named `GITHUB_TOKEN`, using your newly generated access token as the value. 1. Create a `.circleci` directory and create a `config.yml` under that directory. 1. Copy the text below into `.circleci/config.yml`. @@ -160,23 +160,23 @@ Make sure to replace all `<....>` in the `command:` sequence with appropriate va Now, whenever a new commit lands in `master`, CircleCI will run your suite of tests and, if everything passes, your website will be deployed via the `publish-gh-pages` script. -> If you would rather use a deploy key instead of a personal access token, you can by starting with the Circle CI [instructions](https://circleci.com/docs/1.0/adding-read-write-deployment-key/) for adding a read/write deploy key. +> If you would rather use a deploy key instead of a personal access token, you can by starting with the CircleCI [instructions](https://circleci.com/docs/1.0/adding-read-write-deployment-key/) for adding a read/write deploy key. ### Tips & Tricks -When initially deploying to a `gh-pages` branch using Circle CI, you may notice that some jobs triggered by commits to the `gh-pages` branch fail to run successfully due to a lack of tests (This can also result in chat/slack build failure notifications). +When initially deploying to a `gh-pages` branch using CircleCI, you may notice that some jobs triggered by commits to the `gh-pages` branch fail to run successfully due to a lack of tests (This can also result in chat/slack build failure notifications). You can work around this easily by: - Setting the environment variable `CUSTOM_COMMIT_MESSAGE` flag to the `publish-gh-pages` command with the contents of `[skip ci]`. -e.g. +e.g. ```bash CUSTOM_COMMIT_MESSAGE="[skip ci]" \ yarn run publish-gh-pages # or `npm run publish-gh-pages` ``` -- Alternatively you can work around this by creating a basic Circle CI config with the following contents: +- Alternatively you can work around this by creating a basic CircleCI config with the following contents: ```yaml -# Circle CI 2.0 Config File +# CircleCI 2.0 Config File # This config file will prevent tests from being run on the gh-pages branch. version: 2 jobs: diff --git a/website-1.x/blog/2018-04-30-How-I-Converted-Profilo-To-Docusaurus.md b/website-1.x/blog/2018-04-30-How-I-Converted-Profilo-To-Docusaurus.md index 07fa215c79..52e4f7c869 100644 --- a/website-1.x/blog/2018-04-30-How-I-Converted-Profilo-To-Docusaurus.md +++ b/website-1.x/blog/2018-04-30-How-I-Converted-Profilo-To-Docusaurus.md @@ -78,7 +78,7 @@ Here's an overview of the steps taken to convert to a website. I'll discuss some CURRENT_BRANCH=master \ yarn run publish-gh-pages -1. Configured Circle CI using the [provided Docusaurus instructions](https://docusaurus.io/docs/en/publishing.html#automating-deployments-using-continuous-integration). There were 2 PRs for this, [the first](https://github.com/facebookincubator/profilo/pull/8)for the initial config and [the second](https://github.com/facebookincubator/profilo/pull/12) to make sure Circle CI only triggered for changes in the master branch (thanks Joel Marcey!). +1. Configured CircleCI using the [provided Docusaurus instructions](https://docusaurus.io/docs/en/publishing.html#automating-deployments-using-continuous-integration). There were 2 PRs for this, [the first](https://github.com/facebookincubator/profilo/pull/8)for the initial config and [the second](https://github.com/facebookincubator/profilo/pull/12) to make sure CircleCI only triggered for changes in the master branch (thanks Joel Marcey!). The final website was published on https://facebookincubator.github.io/profilo/. It had taken 1.5 hours to get to the initial PR stage and another half an hour or so to respond to review feedback and publish the website. diff --git a/website-1.x/static/.circleci/config.yml b/website-1.x/static/.circleci/config.yml index 14aa03f46d..e7e773953a 100644 --- a/website-1.x/static/.circleci/config.yml +++ b/website-1.x/static/.circleci/config.yml @@ -1,4 +1,4 @@ -# Circle CI 2.0 Config File +# CircleCI 2.0 Config File # This config file will prevent tests from being run on the gh-pages branch. version: 2 jobs: @@ -7,4 +7,4 @@ jobs: branches: ignore: gh-pages steps: - -run: echo "Skipping tests on gh-pages branch" \ No newline at end of file + -run: echo "Skipping tests on gh-pages branch" diff --git a/website-1.x/versioned_docs/version-1.0.11/api-commands.md b/website-1.x/versioned_docs/version-1.0.11/api-commands.md index f9eee77ec7..8d4a471534 100644 --- a/website-1.x/versioned_docs/version-1.0.11/api-commands.md +++ b/website-1.x/versioned_docs/version-1.0.11/api-commands.md @@ -73,7 +73,7 @@ When no feature is specified, sets up a minimally configured example website in ### `docusaurus-publish` Alias: `publish-gh-pages` -[Builds](api-commands.md#docusaurus-build), then deploys the static website to GitHub Pages. This command is meant to be run during the deployment step in Circle CI, and therefore expects a few environment variables to be defined: +[Builds](api-commands.md#docusaurus-build), then deploys the static website to GitHub Pages. This command is meant to be run during the deployment step in CircleCI, and therefore expects a few environment variables to be defined: The following environment variables are generally set manually by the user in the CircleCI `config.yml` file. diff --git a/website-1.x/versioned_docs/version-1.0.11/getting-started-publishing.md b/website-1.x/versioned_docs/version-1.0.11/getting-started-publishing.md index 51b2752c06..16342b4ec2 100644 --- a/website-1.x/versioned_docs/version-1.0.11/getting-started-publishing.md +++ b/website-1.x/versioned_docs/version-1.0.11/getting-started-publishing.md @@ -72,16 +72,16 @@ However, you can automate the publishing process with continuous integration (CI ## Automating Deployments Using Continuous Integration -Continuous integration (CI) services are typically used to perform routine tasks whenever new commits are checked in to source control. These tasks can be any combination of running unit tests and integration tests, automating builds, publishing packages to NPM, and yes, deploying changes to your website. All you need to do to automate deployment of your website is to invoke the `publish-gh-pages` script whenever your docs get updated. In the following section we'll be covering how to do just that using [Circle CI](https://circleci.com/), a popular continuous integration service provider. +Continuous integration (CI) services are typically used to perform routine tasks whenever new commits are checked in to source control. These tasks can be any combination of running unit tests and integration tests, automating builds, publishing packages to NPM, and yes, deploying changes to your website. All you need to do to automate deployment of your website is to invoke the `publish-gh-pages` script whenever your docs get updated. In the following section we'll be covering how to do just that using [CircleCI](https://circleci.com/), a popular continuous integration service provider. -### Using Circle CI 2.0 +### Using CircleCI 2.0 If you haven't done so already, you can [setup CircleCI](https://circleci.com/signup/) for your open source project. Afterwards, in order to enable automatic deployment of your site and documentation via CircleCI, just configure Circle to run the `publish-gh-pages` script as part of the deployment step. You can follow the steps below to get that setup. 1. Ensure the GitHub account that will be set as the `GIT_USER` has `write` access to the repo that contains the documentation, by checking `Settings | Collaborators & teams` in the repo. 1. Log into GitHub as the `GIT_USER`. 1. Go to https://github.com/settings/tokens for the `GIT_USER` and generate a new [personal access token](https://help.github.com/articles/creating-a-personal-access-token-for-the-command-line/), granting it full control of private repositories through the `repo` access scope. Store this token in a safe place, making sure to not share it with anyone. This token can be used to authenticate GitHub actions on your behalf in place of your GitHub password. -1. Open your Circle CI dashboard, and navigate to the Settings page for your repository, then select "Environment variables". The URL looks like https://circleci.com/gh/ORG/REPO/edit#env-vars, where "ORG/REPO" should be replaced with your own GitHub org/repo. +1. Open your CircleCI dashboard, and navigate to the Settings page for your repository, then select "Environment variables". The URL looks like https://circleci.com/gh/ORG/REPO/edit#env-vars, where "ORG/REPO" should be replaced with your own GitHub org/repo. 1. Create a new environment variable named `GITHUB_TOKEN`, using your newly generated access token as the value. 1. Create a `.circleci` folder and create a `config.yml` under that folder. 1. Copy the text below into `.circleci/config.yml`. @@ -118,7 +118,7 @@ workflows: build_and_deploy: jobs: - deploy-website: -# filters: *filter-only-master +# filters: *filter-only-master ``` Make sure to replace all `<....>` in the `command:` sequence with appropriate values. For ``, it should be a GitHub account that has access to push documentation to your GitHub repo. Many times `` and `` will be the same. @@ -131,14 +131,14 @@ Make sure to replace all `<....>` in the `command:` sequence with appropriate va Now, whenever a new commit lands in `master`, CircleCI will run your suite of tests and, if everything passes, your website will be deployed via the `publish-gh-pages` script. -> If you would rather use a deploy key instead of a personal access token, you can by starting with the Circle CI [instructions](https://circleci.com/docs/1.0/adding-read-write-deployment-key/) for adding a read/write deploy key. +> If you would rather use a deploy key instead of a personal access token, you can by starting with the CircleCI [instructions](https://circleci.com/docs/1.0/adding-read-write-deployment-key/) for adding a read/write deploy key. ### Tips & Tricks -When initially deploying to a `gh-pages` branch using Circle CI, you may notice that some jobs triggered by commits to the `gh-pages` branch fail to run successfully due to a lack of tests. You can easily work around this by creating a basic Circle CI config with the following contents: +When initially deploying to a `gh-pages` branch using CircleCI, you may notice that some jobs triggered by commits to the `gh-pages` branch fail to run successfully due to a lack of tests. You can easily work around this by creating a basic CircleCI config with the following contents: ```yml -# Circle CI 2.0 Config File +# CircleCI 2.0 Config File # This config file will prevent tests from being run on the gh-pages branch. version: 2 jobs: diff --git a/website-1.x/versioned_docs/version-1.0.12/getting-started-publishing.md b/website-1.x/versioned_docs/version-1.0.12/getting-started-publishing.md index 1c5e6f3817..1356ee4204 100644 --- a/website-1.x/versioned_docs/version-1.0.12/getting-started-publishing.md +++ b/website-1.x/versioned_docs/version-1.0.12/getting-started-publishing.md @@ -77,16 +77,16 @@ However, you can automate the publishing process with continuous integration (CI ## Automating Deployments Using Continuous Integration -Continuous integration (CI) services are typically used to perform routine tasks whenever new commits are checked in to source control. These tasks can be any combination of running unit tests and integration tests, automating builds, publishing packages to NPM, and yes, deploying changes to your website. All you need to do to automate deployment of your website is to invoke the `publish-gh-pages` script whenever your docs get updated. In the following section we'll be covering how to do just that using [Circle CI](https://circleci.com/), a popular continuous integration service provider. +Continuous integration (CI) services are typically used to perform routine tasks whenever new commits are checked in to source control. These tasks can be any combination of running unit tests and integration tests, automating builds, publishing packages to NPM, and yes, deploying changes to your website. All you need to do to automate deployment of your website is to invoke the `publish-gh-pages` script whenever your docs get updated. In the following section we'll be covering how to do just that using [CircleCI](https://circleci.com/), a popular continuous integration service provider. -### Using Circle CI 2.0 +### Using CircleCI 2.0 If you haven't done so already, you can [setup CircleCI](https://circleci.com/signup/) for your open source project. Afterwards, in order to enable automatic deployment of your site and documentation via CircleCI, just configure Circle to run the `publish-gh-pages` script as part of the deployment step. You can follow the steps below to get that setup. 1. Ensure the GitHub account that will be set as the `GIT_USER` has `write` access to the repo that contains the documentation, by checking `Settings | Collaborators & teams` in the repo. 1. Log into GitHub as the `GIT_USER`. 1. Go to https://github.com/settings/tokens for the `GIT_USER` and generate a new [personal access token](https://help.github.com/articles/creating-a-personal-access-token-for-the-command-line/), granting it full control of private repositories through the `repo` access scope. Store this token in a safe place, making sure to not share it with anyone. This token can be used to authenticate GitHub actions on your behalf in place of your GitHub password. -1. Open your Circle CI dashboard, and navigate to the Settings page for your repository, then select "Environment variables". The URL looks like https://circleci.com/gh/ORG/REPO/edit#env-vars, where "ORG/REPO" should be replaced with your own GitHub org/repo. +1. Open your CircleCI dashboard, and navigate to the Settings page for your repository, then select "Environment variables". The URL looks like https://circleci.com/gh/ORG/REPO/edit#env-vars, where "ORG/REPO" should be replaced with your own GitHub org/repo. 1. Create a new environment variable named `GITHUB_TOKEN`, using your newly generated access token as the value. 1. Create a `.circleci` folder and create a `config.yml` under that folder. 1. Copy the text below into `.circleci/config.yml`. @@ -136,14 +136,14 @@ Make sure to replace all `<....>` in the `command:` sequence with appropriate va Now, whenever a new commit lands in `master`, CircleCI will run your suite of tests and, if everything passes, your website will be deployed via the `publish-gh-pages` script. -> If you would rather use a deploy key instead of a personal access token, you can by starting with the Circle CI [instructions](https://circleci.com/docs/1.0/adding-read-write-deployment-key/) for adding a read/write deploy key. +> If you would rather use a deploy key instead of a personal access token, you can by starting with the CircleCI [instructions](https://circleci.com/docs/1.0/adding-read-write-deployment-key/) for adding a read/write deploy key. ### Tips & Tricks -When initially deploying to a `gh-pages` branch using Circle CI, you may notice that some jobs triggered by commits to the `gh-pages` branch fail to run successfully due to a lack of tests. You can easily work around this by creating a basic Circle CI config with the following contents: +When initially deploying to a `gh-pages` branch using CircleCI, you may notice that some jobs triggered by commits to the `gh-pages` branch fail to run successfully due to a lack of tests. You can easily work around this by creating a basic CircleCI config with the following contents: ```yml -# Circle CI 2.0 Config File +# CircleCI 2.0 Config File # This config file will prevent tests from being run on the gh-pages branch. version: 2 jobs: diff --git a/website-1.x/versioned_docs/version-1.0.14/getting-started-publishing.md b/website-1.x/versioned_docs/version-1.0.14/getting-started-publishing.md index 5ae2e612ff..d68d68bb45 100644 --- a/website-1.x/versioned_docs/version-1.0.14/getting-started-publishing.md +++ b/website-1.x/versioned_docs/version-1.0.14/getting-started-publishing.md @@ -82,16 +82,16 @@ However, you can automate the publishing process with continuous integration (CI ## Automating Deployments Using Continuous Integration -Continuous integration (CI) services are typically used to perform routine tasks whenever new commits are checked in to source control. These tasks can be any combination of running unit tests and integration tests, automating builds, publishing packages to NPM, and yes, deploying changes to your website. All you need to do to automate deployment of your website is to invoke the `publish-gh-pages` script whenever your docs get updated. In the following section we'll be covering how to do just that using [Circle CI](https://circleci.com/), a popular continuous integration service provider. +Continuous integration (CI) services are typically used to perform routine tasks whenever new commits are checked in to source control. These tasks can be any combination of running unit tests and integration tests, automating builds, publishing packages to NPM, and yes, deploying changes to your website. All you need to do to automate deployment of your website is to invoke the `publish-gh-pages` script whenever your docs get updated. In the following section we'll be covering how to do just that using [CircleCI](https://circleci.com/), a popular continuous integration service provider. -### Using Circle CI 2.0 +### Using CircleCI 2.0 If you haven't done so already, you can [setup CircleCI](https://circleci.com/signup/) for your open source project. Afterwards, in order to enable automatic deployment of your site and documentation via CircleCI, just configure Circle to run the `publish-gh-pages` script as part of the deployment step. You can follow the steps below to get that setup. 1. Ensure the GitHub account that will be set as the `GIT_USER` has `write` access to the repo that contains the documentation, by checking `Settings | Collaborators & teams` in the repo. 1. Log into GitHub as the `GIT_USER`. 1. Go to https://github.com/settings/tokens for the `GIT_USER` and generate a new [personal access token](https://help.github.com/articles/creating-a-personal-access-token-for-the-command-line/), granting it full control of private repositories through the `repo` access scope. Store this token in a safe place, making sure to not share it with anyone. This token can be used to authenticate GitHub actions on your behalf in place of your GitHub password. -1. Open your Circle CI dashboard, and navigate to the Settings page for your repository, then select "Environment variables". The URL looks like https://circleci.com/gh/ORG/REPO/edit#env-vars, where "ORG/REPO" should be replaced with your own GitHub org/repo. +1. Open your CircleCI dashboard, and navigate to the Settings page for your repository, then select "Environment variables". The URL looks like https://circleci.com/gh/ORG/REPO/edit#env-vars, where "ORG/REPO" should be replaced with your own GitHub org/repo. 1. Create a new environment variable named `GITHUB_TOKEN`, using your newly generated access token as the value. 1. Create a `.circleci` folder and create a `config.yml` under that folder. 1. Copy the text below into `.circleci/config.yml`. @@ -141,14 +141,14 @@ Make sure to replace all `<....>` in the `command:` sequence with appropriate va Now, whenever a new commit lands in `master`, CircleCI will run your suite of tests and, if everything passes, your website will be deployed via the `publish-gh-pages` script. -> If you would rather use a deploy key instead of a personal access token, you can by starting with the Circle CI [instructions](https://circleci.com/docs/1.0/adding-read-write-deployment-key/) for adding a read/write deploy key. +> If you would rather use a deploy key instead of a personal access token, you can by starting with the CircleCI [instructions](https://circleci.com/docs/1.0/adding-read-write-deployment-key/) for adding a read/write deploy key. ### Tips & Tricks -When initially deploying to a `gh-pages` branch using Circle CI, you may notice that some jobs triggered by commits to the `gh-pages` branch fail to run successfully due to a lack of tests. You can easily work around this by creating a basic Circle CI config with the following contents: +When initially deploying to a `gh-pages` branch using CircleCI, you may notice that some jobs triggered by commits to the `gh-pages` branch fail to run successfully due to a lack of tests. You can easily work around this by creating a basic CircleCI config with the following contents: ```yml -# Circle CI 2.0 Config File +# CircleCI 2.0 Config File # This config file will prevent tests from being run on the gh-pages branch. version: 2 jobs: diff --git a/website-1.x/versioned_docs/version-1.0.15/api-commands.md b/website-1.x/versioned_docs/version-1.0.15/api-commands.md index 0088d76772..239a7be440 100644 --- a/website-1.x/versioned_docs/version-1.0.15/api-commands.md +++ b/website-1.x/versioned_docs/version-1.0.15/api-commands.md @@ -76,7 +76,7 @@ When no feature is specified, sets up a minimally configured example website in Alias: `publish-gh-pages` -[Builds](api-commands.md#docusaurus-build), then deploys the static website to GitHub Pages. This command is meant to be run during the deployment step in Circle CI, and therefore expects a few environment variables to be defined: +[Builds](api-commands.md#docusaurus-build), then deploys the static website to GitHub Pages. This command is meant to be run during the deployment step in CircleCI, and therefore expects a few environment variables to be defined: The following environment variables are generally set manually by the user in the CircleCI `config.yml` file. diff --git a/website-1.x/versioned_docs/version-1.0.15/getting-started-publishing.md b/website-1.x/versioned_docs/version-1.0.15/getting-started-publishing.md index 7f1bcb7063..3e99d9fd7d 100644 --- a/website-1.x/versioned_docs/version-1.0.15/getting-started-publishing.md +++ b/website-1.x/versioned_docs/version-1.0.15/getting-started-publishing.md @@ -84,16 +84,16 @@ However, you can automate the publishing process with continuous integration (CI ## Automating Deployments Using Continuous Integration -Continuous integration (CI) services are typically used to perform routine tasks whenever new commits are checked in to source control. These tasks can be any combination of running unit tests and integration tests, automating builds, publishing packages to NPM, and yes, deploying changes to your website. All you need to do to automate deployment of your website is to invoke the `publish-gh-pages` script whenever your docs get updated. In the following section we'll be covering how to do just that using [Circle CI](https://circleci.com/), a popular continuous integration service provider. +Continuous integration (CI) services are typically used to perform routine tasks whenever new commits are checked in to source control. These tasks can be any combination of running unit tests and integration tests, automating builds, publishing packages to NPM, and yes, deploying changes to your website. All you need to do to automate deployment of your website is to invoke the `publish-gh-pages` script whenever your docs get updated. In the following section we'll be covering how to do just that using [CircleCI](https://circleci.com/), a popular continuous integration service provider. -### Using Circle CI 2.0 +### Using CircleCI 2.0 If you haven't done so already, you can [setup CircleCI](https://circleci.com/signup/) for your open source project. Afterwards, in order to enable automatic deployment of your site and documentation via CircleCI, just configure Circle to run the `publish-gh-pages` script as part of the deployment step. You can follow the steps below to get that setup. 1. Ensure the GitHub account that will be set as the `GIT_USER` has `write` access to the repo that contains the documentation, by checking `Settings | Collaborators & teams` in the repo. 1. Log into GitHub as the `GIT_USER`. 1. Go to https://github.com/settings/tokens for the `GIT_USER` and generate a new [personal access token](https://help.github.com/articles/creating-a-personal-access-token-for-the-command-line/), granting it full control of private repositories through the `repo` access scope. Store this token in a safe place, making sure to not share it with anyone. This token can be used to authenticate GitHub actions on your behalf in place of your GitHub password. -1. Open your Circle CI dashboard, and navigate to the Settings page for your repository, then select "Environment variables". The URL looks like https://circleci.com/gh/ORG/REPO/edit#env-vars, where "ORG/REPO" should be replaced with your own GitHub org/repo. +1. Open your CircleCI dashboard, and navigate to the Settings page for your repository, then select "Environment variables". The URL looks like https://circleci.com/gh/ORG/REPO/edit#env-vars, where "ORG/REPO" should be replaced with your own GitHub org/repo. 1. Create a new environment variable named `GITHUB_TOKEN`, using your newly generated access token as the value. 1. Create a `.circleci` folder and create a `config.yml` under that folder. 1. Copy the text below into `.circleci/config.yml`. @@ -143,14 +143,14 @@ Make sure to replace all `<....>` in the `command:` sequence with appropriate va Now, whenever a new commit lands in `master`, CircleCI will run your suite of tests and, if everything passes, your website will be deployed via the `publish-gh-pages` script. -> If you would rather use a deploy key instead of a personal access token, you can by starting with the Circle CI [instructions](https://circleci.com/docs/1.0/adding-read-write-deployment-key/) for adding a read/write deploy key. +> If you would rather use a deploy key instead of a personal access token, you can by starting with the CircleCI [instructions](https://circleci.com/docs/1.0/adding-read-write-deployment-key/) for adding a read/write deploy key. ### Tips & Tricks -When initially deploying to a `gh-pages` branch using Circle CI, you may notice that some jobs triggered by commits to the `gh-pages` branch fail to run successfully due to a lack of tests. You can easily work around this by creating a basic Circle CI config with the following contents: +When initially deploying to a `gh-pages` branch using CircleCI, you may notice that some jobs triggered by commits to the `gh-pages` branch fail to run successfully due to a lack of tests. You can easily work around this by creating a basic CircleCI config with the following contents: ```yaml -# Circle CI 2.0 Config File +# CircleCI 2.0 Config File # This config file will prevent tests from being run on the gh-pages branch. version: 2 jobs: diff --git a/website-1.x/versioned_docs/version-1.1.0/api-commands.md b/website-1.x/versioned_docs/version-1.1.0/api-commands.md index 9e47576314..4498b8b124 100644 --- a/website-1.x/versioned_docs/version-1.1.0/api-commands.md +++ b/website-1.x/versioned_docs/version-1.1.0/api-commands.md @@ -90,7 +90,7 @@ When no feature is specified, sets up a minimally configured example website in Alias: `publish-gh-pages` -[Builds](api-commands.md#docusaurus-build), then deploys the static website to GitHub Pages. This command is meant to be run during the deployment step in Circle CI, and therefore expects a few environment variables to be defined: +[Builds](api-commands.md#docusaurus-build), then deploys the static website to GitHub Pages. This command is meant to be run during the deployment step in CircleCI, and therefore expects a few environment variables to be defined: The following environment variables are generally set manually by the user in the CircleCI `config.yml` file. diff --git a/website-1.x/versioned_docs/version-1.1.0/getting-started-publishing.md b/website-1.x/versioned_docs/version-1.1.0/getting-started-publishing.md index a7404c5898..236697ec43 100644 --- a/website-1.x/versioned_docs/version-1.1.0/getting-started-publishing.md +++ b/website-1.x/versioned_docs/version-1.1.0/getting-started-publishing.md @@ -84,16 +84,16 @@ However, you can automate the publishing process with continuous integration (CI ## Automating Deployments Using Continuous Integration -Continuous integration (CI) services are typically used to perform routine tasks whenever new commits are checked in to source control. These tasks can be any combination of running unit tests and integration tests, automating builds, publishing packages to NPM, and yes, deploying changes to your website. All you need to do to automate deployment of your website is to invoke the `publish-gh-pages` script whenever your docs get updated. In the following section we'll be covering how to do just that using [Circle CI](https://circleci.com/), a popular continuous integration service provider. +Continuous integration (CI) services are typically used to perform routine tasks whenever new commits are checked in to source control. These tasks can be any combination of running unit tests and integration tests, automating builds, publishing packages to NPM, and yes, deploying changes to your website. All you need to do to automate deployment of your website is to invoke the `publish-gh-pages` script whenever your docs get updated. In the following section we'll be covering how to do just that using [CircleCI](https://circleci.com/), a popular continuous integration service provider. -### Using Circle CI 2.0 +### Using CircleCI 2.0 If you haven't done so already, you can [setup CircleCI](https://circleci.com/signup/) for your open source project. Afterwards, in order to enable automatic deployment of your site and documentation via CircleCI, just configure Circle to run the `publish-gh-pages` script as part of the deployment step. You can follow the steps below to get that setup. 1. Ensure the GitHub account that will be set as the `GIT_USER` has `write` access to the repo that contains the documentation, by checking `Settings | Collaborators & teams` in the repo. 1. Log into GitHub as the `GIT_USER`. 1. Go to https://github.com/settings/tokens for the `GIT_USER` and generate a new [personal access token](https://help.github.com/articles/creating-a-personal-access-token-for-the-command-line/), granting it full control of private repositories through the `repo` access scope. Store this token in a safe place, making sure to not share it with anyone. This token can be used to authenticate GitHub actions on your behalf in place of your GitHub password. -1. Open your Circle CI dashboard, and navigate to the Settings page for your repository, then select "Environment variables". The URL looks like https://circleci.com/gh/ORG/REPO/edit#env-vars, where "ORG/REPO" should be replaced with your own GitHub org/repo. +1. Open your CircleCI dashboard, and navigate to the Settings page for your repository, then select "Environment variables". The URL looks like https://circleci.com/gh/ORG/REPO/edit#env-vars, where "ORG/REPO" should be replaced with your own GitHub org/repo. 1. Create a new environment variable named `GITHUB_TOKEN`, using your newly generated access token as the value. 1. Create a `.circleci` folder and create a `config.yml` under that folder. 1. Copy the text below into `.circleci/config.yml`. @@ -143,14 +143,14 @@ Make sure to replace all `<....>` in the `command:` sequence with appropriate va Now, whenever a new commit lands in `master`, CircleCI will run your suite of tests and, if everything passes, your website will be deployed via the `publish-gh-pages` script. -> If you would rather use a deploy key instead of a personal access token, you can by starting with the Circle CI [instructions](https://circleci.com/docs/1.0/adding-read-write-deployment-key/) for adding a read/write deploy key. +> If you would rather use a deploy key instead of a personal access token, you can by starting with the CircleCI [instructions](https://circleci.com/docs/1.0/adding-read-write-deployment-key/) for adding a read/write deploy key. ### Tips & Tricks -When initially deploying to a `gh-pages` branch using Circle CI, you may notice that some jobs triggered by commits to the `gh-pages` branch fail to run successfully due to a lack of tests. You can easily work around this by creating a basic Circle CI config with the following contents: +When initially deploying to a `gh-pages` branch using CircleCI, you may notice that some jobs triggered by commits to the `gh-pages` branch fail to run successfully due to a lack of tests. You can easily work around this by creating a basic CircleCI config with the following contents: ```yaml -# Circle CI 2.0 Config File +# CircleCI 2.0 Config File # This config file will prevent tests from being run on the gh-pages branch. version: 2 jobs: diff --git a/website-1.x/versioned_docs/version-1.2.0/api-commands.md b/website-1.x/versioned_docs/version-1.2.0/api-commands.md index 6c44d7a5ff..5c968976cc 100644 --- a/website-1.x/versioned_docs/version-1.2.0/api-commands.md +++ b/website-1.x/versioned_docs/version-1.2.0/api-commands.md @@ -89,7 +89,7 @@ When no feature is specified, sets up a minimally configured example website in Alias: `publish-gh-pages` -[Builds](api-commands.md#docusaurus-build), then deploys the static website to GitHub Pages. This command is meant to be run during the deployment step in Circle CI, and therefore expects a few environment variables to be defined: +[Builds](api-commands.md#docusaurus-build), then deploys the static website to GitHub Pages. This command is meant to be run during the deployment step in CircleCI, and therefore expects a few environment variables to be defined: The following environment variables are generally set manually by the user in the CircleCI `config.yml` file. diff --git a/website-1.x/versioned_docs/version-1.2.0/getting-started-publishing.md b/website-1.x/versioned_docs/version-1.2.0/getting-started-publishing.md index ec212e6f3a..22f3c4ef5e 100644 --- a/website-1.x/versioned_docs/version-1.2.0/getting-started-publishing.md +++ b/website-1.x/versioned_docs/version-1.2.0/getting-started-publishing.md @@ -84,16 +84,16 @@ However, you can automate the publishing process with continuous integration (CI ## Automating Deployments Using Continuous Integration -Continuous integration (CI) services are typically used to perform routine tasks whenever new commits are checked in to source control. These tasks can be any combination of running unit tests and integration tests, automating builds, publishing packages to NPM, and yes, deploying changes to your website. All you need to do to automate deployment of your website is to invoke the `publish-gh-pages` script whenever your docs get updated. In the following section we'll be covering how to do just that using [Circle CI](https://circleci.com/), a popular continuous integration service provider. +Continuous integration (CI) services are typically used to perform routine tasks whenever new commits are checked in to source control. These tasks can be any combination of running unit tests and integration tests, automating builds, publishing packages to NPM, and yes, deploying changes to your website. All you need to do to automate deployment of your website is to invoke the `publish-gh-pages` script whenever your docs get updated. In the following section we'll be covering how to do just that using [CircleCI](https://circleci.com/), a popular continuous integration service provider. -### Using Circle CI 2.0 +### Using CircleCI 2.0 If you haven't done so already, you can [setup CircleCI](https://circleci.com/signup/) for your open source project. Afterwards, in order to enable automatic deployment of your site and documentation via CircleCI, just configure Circle to run the `publish-gh-pages` script as part of the deployment step. You can follow the steps below to get that setup. 1. Ensure the GitHub account that will be set as the `GIT_USER` has `write` access to the repository that contains the documentation, by checking `Settings | Collaborators & teams` in the repository. 1. Log into GitHub as the `GIT_USER`. 1. Go to https://github.com/settings/tokens for the `GIT_USER` and generate a new [personal access token](https://help.github.com/articles/creating-a-personal-access-token-for-the-command-line/), granting it full control of private repositories through the `repository` access scope. Store this token in a safe place, making sure to not share it with anyone. This token can be used to authenticate GitHub actions on your behalf in place of your GitHub password. -1. Open your Circle CI dashboard, and navigate to the Settings page for your repository, then select "Environment variables". The URL looks like https://circleci.com/gh/ORG/REPO/edit#env-vars, where "ORG/REPO" should be replaced with your own GitHub organization/repository. +1. Open your CircleCI dashboard, and navigate to the Settings page for your repository, then select "Environment variables". The URL looks like https://circleci.com/gh/ORG/REPO/edit#env-vars, where "ORG/REPO" should be replaced with your own GitHub organization/repository. 1. Create a new environment variable named `GITHUB_TOKEN`, using your newly generated access token as the value. 1. Create a `.circleci` directory and create a `config.yml` under that directory. 1. Copy the text below into `.circleci/config.yml`. @@ -143,14 +143,14 @@ Make sure to replace all `<....>` in the `command:` sequence with appropriate va Now, whenever a new commit lands in `master`, CircleCI will run your suite of tests and, if everything passes, your website will be deployed via the `publish-gh-pages` script. -> If you would rather use a deploy key instead of a personal access token, you can by starting with the Circle CI [instructions](https://circleci.com/docs/1.0/adding-read-write-deployment-key/) for adding a read/write deploy key. +> If you would rather use a deploy key instead of a personal access token, you can by starting with the CircleCI [instructions](https://circleci.com/docs/1.0/adding-read-write-deployment-key/) for adding a read/write deploy key. ### Tips & Tricks -When initially deploying to a `gh-pages` branch using Circle CI, you may notice that some jobs triggered by commits to the `gh-pages` branch fail to run successfully due to a lack of tests. You can easily work around this by creating a basic Circle CI config with the following contents: +When initially deploying to a `gh-pages` branch using CircleCI, you may notice that some jobs triggered by commits to the `gh-pages` branch fail to run successfully due to a lack of tests. You can easily work around this by creating a basic CircleCI config with the following contents: ```yaml -# Circle CI 2.0 Config File +# CircleCI 2.0 Config File # This config file will prevent tests from being run on the gh-pages branch. version: 2 jobs: diff --git a/website-1.x/versioned_docs/version-1.2.1/api-commands.md b/website-1.x/versioned_docs/version-1.2.1/api-commands.md index 4c05a7b33d..e3cdd72561 100644 --- a/website-1.x/versioned_docs/version-1.2.1/api-commands.md +++ b/website-1.x/versioned_docs/version-1.2.1/api-commands.md @@ -89,7 +89,7 @@ When no feature is specified, sets up a minimally configured example website in Alias: `publish-gh-pages` -[Builds](api-commands.md#docusaurus-build), then deploys the static website to GitHub Pages. This command is meant to be run during the deployment step in Circle CI, and therefore expects a few environment variables to be defined: +[Builds](api-commands.md#docusaurus-build), then deploys the static website to GitHub Pages. This command is meant to be run during the deployment step in CircleCI, and therefore expects a few environment variables to be defined: The following environment variables are generally set manually by the user in the CircleCI `config.yml` file. diff --git a/website-1.x/versioned_docs/version-1.2.1/getting-started-publishing.md b/website-1.x/versioned_docs/version-1.2.1/getting-started-publishing.md index 6e20f1ee71..dd7ea8f9a2 100644 --- a/website-1.x/versioned_docs/version-1.2.1/getting-started-publishing.md +++ b/website-1.x/versioned_docs/version-1.2.1/getting-started-publishing.md @@ -46,7 +46,7 @@ Two of the required parameters are set in the [`siteConfig.js`](api-site-config. | `organizationName` | The GitHub user or organization that owns the repository. In the case of Docusaurus, that would be the "facebook" GitHub organization. | | `projectName` | The name of the GitHub repository for your project. For example, Docusaurus is hosted at https://github.com/facebook/docusaurus, so our project name in this case would be "docusaurus". | -> Docusaurus also supports deploying [user or organization sites](https://help.github.com/articles/user-organization-and-project-pages/#user--organization-pages). To do this, just set `projectName` to "_username_.github.io" (where _username_ is your username or organization name on GitHub) and `organizationName` to "_username_". +> Docusaurus also supports deploying [user or organization sites](https://help.github.com/articles/user-organization-and-project-pages/#user--organization-pages). To do this, just set `projectName` to "_username_.github.io" (where _username_ is your username or organization name on GitHub) and `organizationName` to "_username_". > For user or org sites, the publish script will deploy these sites to the root of the `master` branch of the _username_.github.io repo. In this case, note that you will want to have the Docusaurus infra, your docs, etc. either in another branch of the _username_.github.io repo (e.g., maybe call it `source`), or in another, separated repo (e.g. in the same as the documented source code). > While we recommend setting the `projectName` and `organizationName` in `siteConfig.js`, you can also use environment variables `ORGANIZATION_NAME` and `PROJECT_NAME`. @@ -85,16 +85,16 @@ However, you can automate the publishing process with continuous integration (CI ## Automating Deployments Using Continuous Integration -Continuous integration (CI) services are typically used to perform routine tasks whenever new commits are checked in to source control. These tasks can be any combination of running unit tests and integration tests, automating builds, publishing packages to NPM, and yes, deploying changes to your website. All you need to do to automate deployment of your website is to invoke the `publish-gh-pages` script whenever your docs get updated. In the following section we'll be covering how to do just that using [Circle CI](https://circleci.com/), a popular continuous integration service provider. +Continuous integration (CI) services are typically used to perform routine tasks whenever new commits are checked in to source control. These tasks can be any combination of running unit tests and integration tests, automating builds, publishing packages to NPM, and yes, deploying changes to your website. All you need to do to automate deployment of your website is to invoke the `publish-gh-pages` script whenever your docs get updated. In the following section we'll be covering how to do just that using [CircleCI](https://circleci.com/), a popular continuous integration service provider. -### Using Circle CI 2.0 +### Using CircleCI 2.0 If you haven't done so already, you can [setup CircleCI](https://circleci.com/signup/) for your open source project. Afterwards, in order to enable automatic deployment of your site and documentation via CircleCI, just configure Circle to run the `publish-gh-pages` script as part of the deployment step. You can follow the steps below to get that setup. 1. Ensure the GitHub account that will be set as the `GIT_USER` has `write` access to the repository that contains the documentation, by checking `Settings | Collaborators & teams` in the repository. 1. Log into GitHub as the `GIT_USER`. 1. Go to https://github.com/settings/tokens for the `GIT_USER` and generate a new [personal access token](https://help.github.com/articles/creating-a-personal-access-token-for-the-command-line/), granting it full control of private repositories through the `repository` access scope. Store this token in a safe place, making sure to not share it with anyone. This token can be used to authenticate GitHub actions on your behalf in place of your GitHub password. -1. Open your Circle CI dashboard, and navigate to the Settings page for your repository, then select "Environment variables". The URL looks like https://circleci.com/gh/ORG/REPO/edit#env-vars, where "ORG/REPO" should be replaced with your own GitHub organization/repository. +1. Open your CircleCI dashboard, and navigate to the Settings page for your repository, then select "Environment variables". The URL looks like https://circleci.com/gh/ORG/REPO/edit#env-vars, where "ORG/REPO" should be replaced with your own GitHub organization/repository. 1. Create a new environment variable named `GITHUB_TOKEN`, using your newly generated access token as the value. 1. Create a `.circleci` directory and create a `config.yml` under that directory. 1. Copy the text below into `.circleci/config.yml`. @@ -144,14 +144,14 @@ Make sure to replace all `<....>` in the `command:` sequence with appropriate va Now, whenever a new commit lands in `master`, CircleCI will run your suite of tests and, if everything passes, your website will be deployed via the `publish-gh-pages` script. -> If you would rather use a deploy key instead of a personal access token, you can by starting with the Circle CI [instructions](https://circleci.com/docs/1.0/adding-read-write-deployment-key/) for adding a read/write deploy key. +> If you would rather use a deploy key instead of a personal access token, you can by starting with the CircleCI [instructions](https://circleci.com/docs/1.0/adding-read-write-deployment-key/) for adding a read/write deploy key. ### Tips & Tricks -When initially deploying to a `gh-pages` branch using Circle CI, you may notice that some jobs triggered by commits to the `gh-pages` branch fail to run successfully due to a lack of tests. You can easily work around this by creating a basic Circle CI config with the following contents: +When initially deploying to a `gh-pages` branch using CircleCI, you may notice that some jobs triggered by commits to the `gh-pages` branch fail to run successfully due to a lack of tests. You can easily work around this by creating a basic CircleCI config with the following contents: ```yaml -# Circle CI 2.0 Config File +# CircleCI 2.0 Config File # This config file will prevent tests from being run on the gh-pages branch. version: 2 jobs: diff --git a/website-1.x/versioned_docs/version-1.5.1/api-commands.md b/website-1.x/versioned_docs/version-1.5.1/api-commands.md index 89c6d9f965..bfeac98150 100644 --- a/website-1.x/versioned_docs/version-1.5.1/api-commands.md +++ b/website-1.x/versioned_docs/version-1.5.1/api-commands.md @@ -89,7 +89,7 @@ When no feature is specified, sets up a minimally configured example website in Alias: `publish-gh-pages` -[Builds](api-commands.md#docusaurus-build), then deploys the static website to GitHub Pages. This command is meant to be run during the deployment step in Circle CI, and therefore expects a few environment variables to be defined: +[Builds](api-commands.md#docusaurus-build), then deploys the static website to GitHub Pages. This command is meant to be run during the deployment step in CircleCI, and therefore expects a few environment variables to be defined: The following environment variables are generally set manually by the user in the CircleCI `config.yml` file. diff --git a/website-1.x/versioned_docs/version-1.5.1/getting-started-publishing.md b/website-1.x/versioned_docs/version-1.5.1/getting-started-publishing.md index 09c6efbfee..8467717625 100644 --- a/website-1.x/versioned_docs/version-1.5.1/getting-started-publishing.md +++ b/website-1.x/versioned_docs/version-1.5.1/getting-started-publishing.md @@ -100,16 +100,16 @@ However, you can automate the publishing process with continuous integration (CI ## Automating Deployments Using Continuous Integration -Continuous integration (CI) services are typically used to perform routine tasks whenever new commits are checked in to source control. These tasks can be any combination of running unit tests and integration tests, automating builds, publishing packages to NPM, and yes, deploying changes to your website. All you need to do to automate deployment of your website is to invoke the `publish-gh-pages` script whenever your docs get updated. In the following section we'll be covering how to do just that using [Circle CI](https://circleci.com/), a popular continuous integration service provider. +Continuous integration (CI) services are typically used to perform routine tasks whenever new commits are checked in to source control. These tasks can be any combination of running unit tests and integration tests, automating builds, publishing packages to NPM, and yes, deploying changes to your website. All you need to do to automate deployment of your website is to invoke the `publish-gh-pages` script whenever your docs get updated. In the following section we'll be covering how to do just that using [CircleCI](https://circleci.com/), a popular continuous integration service provider. -### Using Circle CI 2.0 +### Using CircleCI 2.0 If you haven't done so already, you can [setup CircleCI](https://circleci.com/signup/) for your open source project. Afterwards, in order to enable automatic deployment of your site and documentation via CircleCI, just configure Circle to run the `publish-gh-pages` script as part of the deployment step. You can follow the steps below to get that setup. 1. Ensure the GitHub account that will be set as the `GIT_USER` has `write` access to the repository that contains the documentation, by checking `Settings | Collaborators & teams` in the repository. 1. Log into GitHub as the `GIT_USER`. 1. Go to https://github.com/settings/tokens for the `GIT_USER` and generate a new [personal access token](https://help.github.com/articles/creating-a-personal-access-token-for-the-command-line/), granting it full control of private repositories through the `repository` access scope. Store this token in a safe place, making sure to not share it with anyone. This token can be used to authenticate GitHub actions on your behalf in place of your GitHub password. -1. Open your Circle CI dashboard, and navigate to the Settings page for your repository, then select "Environment variables". The URL looks like https://circleci.com/gh/ORG/REPO/edit#env-vars, where "ORG/REPO" should be replaced with your own GitHub organization/repository. +1. Open your CircleCI dashboard, and navigate to the Settings page for your repository, then select "Environment variables". The URL looks like https://circleci.com/gh/ORG/REPO/edit#env-vars, where "ORG/REPO" should be replaced with your own GitHub organization/repository. 1. Create a new environment variable named `GITHUB_TOKEN`, using your newly generated access token as the value. 1. Create a `.circleci` directory and create a `config.yml` under that directory. 1. Copy the text below into `.circleci/config.yml`. @@ -159,14 +159,14 @@ Make sure to replace all `<....>` in the `command:` sequence with appropriate va Now, whenever a new commit lands in `master`, CircleCI will run your suite of tests and, if everything passes, your website will be deployed via the `publish-gh-pages` script. -> If you would rather use a deploy key instead of a personal access token, you can by starting with the Circle CI [instructions](https://circleci.com/docs/1.0/adding-read-write-deployment-key/) for adding a read/write deploy key. +> If you would rather use a deploy key instead of a personal access token, you can by starting with the CircleCI [instructions](https://circleci.com/docs/1.0/adding-read-write-deployment-key/) for adding a read/write deploy key. ### Tips & Tricks -When initially deploying to a `gh-pages` branch using Circle CI, you may notice that some jobs triggered by commits to the `gh-pages` branch fail to run successfully due to a lack of tests. You can easily work around this by creating a basic Circle CI config with the following contents: +When initially deploying to a `gh-pages` branch using CircleCI, you may notice that some jobs triggered by commits to the `gh-pages` branch fail to run successfully due to a lack of tests. You can easily work around this by creating a basic CircleCI config with the following contents: ```yaml -# Circle CI 2.0 Config File +# CircleCI 2.0 Config File # This config file will prevent tests from being run on the gh-pages branch. version: 2 jobs: diff --git a/website-1.x/versioned_docs/version-1.6.1/getting-started-publishing.md b/website-1.x/versioned_docs/version-1.6.1/getting-started-publishing.md index 22c4b64442..e177b764c0 100644 --- a/website-1.x/versioned_docs/version-1.6.1/getting-started-publishing.md +++ b/website-1.x/versioned_docs/version-1.6.1/getting-started-publishing.md @@ -100,16 +100,16 @@ However, you can automate the publishing process with continuous integration (CI ## Automating Deployments Using Continuous Integration -Continuous integration (CI) services are typically used to perform routine tasks whenever new commits are checked in to source control. These tasks can be any combination of running unit tests and integration tests, automating builds, publishing packages to NPM, and yes, deploying changes to your website. All you need to do to automate deployment of your website is to invoke the `publish-gh-pages` script whenever your docs get updated. In the following section we'll be covering how to do just that using [Circle CI](https://circleci.com/), a popular continuous integration service provider. +Continuous integration (CI) services are typically used to perform routine tasks whenever new commits are checked in to source control. These tasks can be any combination of running unit tests and integration tests, automating builds, publishing packages to NPM, and yes, deploying changes to your website. All you need to do to automate deployment of your website is to invoke the `publish-gh-pages` script whenever your docs get updated. In the following section we'll be covering how to do just that using [CircleCI](https://circleci.com/), a popular continuous integration service provider. -### Using Circle CI 2.0 +### Using CircleCI 2.0 If you haven't done so already, you can [setup CircleCI](https://circleci.com/signup/) for your open source project. Afterwards, in order to enable automatic deployment of your site and documentation via CircleCI, just configure Circle to run the `publish-gh-pages` script as part of the deployment step. You can follow the steps below to get that setup. 1. Ensure the GitHub account that will be set as the `GIT_USER` has `write` access to the repository that contains the documentation, by checking `Settings | Collaborators & teams` in the repository. 1. Log into GitHub as the `GIT_USER`. 1. Go to https://github.com/settings/tokens for the `GIT_USER` and generate a new [personal access token](https://help.github.com/articles/creating-a-personal-access-token-for-the-command-line/), granting it full control of private repositories through the `repository` access scope. Store this token in a safe place, making sure to not share it with anyone. This token can be used to authenticate GitHub actions on your behalf in place of your GitHub password. -1. Open your Circle CI dashboard, and navigate to the Settings page for your repository, then select "Environment variables". The URL looks like https://circleci.com/gh/ORG/REPO/edit#env-vars, where "ORG/REPO" should be replaced with your own GitHub organization/repository. +1. Open your CircleCI dashboard, and navigate to the Settings page for your repository, then select "Environment variables". The URL looks like https://circleci.com/gh/ORG/REPO/edit#env-vars, where "ORG/REPO" should be replaced with your own GitHub organization/repository. 1. Create a new environment variable named `GITHUB_TOKEN`, using your newly generated access token as the value. 1. Create a `.circleci` directory and create a `config.yml` under that directory. 1. Copy the text below into `.circleci/config.yml`. @@ -159,23 +159,23 @@ Make sure to replace all `<....>` in the `command:` sequence with appropriate va Now, whenever a new commit lands in `master`, CircleCI will run your suite of tests and, if everything passes, your website will be deployed via the `publish-gh-pages` script. -> If you would rather use a deploy key instead of a personal access token, you can by starting with the Circle CI [instructions](https://circleci.com/docs/1.0/adding-read-write-deployment-key/) for adding a read/write deploy key. +> If you would rather use a deploy key instead of a personal access token, you can by starting with the CircleCI [instructions](https://circleci.com/docs/1.0/adding-read-write-deployment-key/) for adding a read/write deploy key. ### Tips & Tricks -When initially deploying to a `gh-pages` branch using Circle CI, you may notice that some jobs triggered by commits to the `gh-pages` branch fail to run successfully due to a lack of tests (This can also result in chat/slack build failure notifications). +When initially deploying to a `gh-pages` branch using CircleCI, you may notice that some jobs triggered by commits to the `gh-pages` branch fail to run successfully due to a lack of tests (This can also result in chat/slack build failure notifications). You can work around this easily by: - Setting the environment variable `CUSTOM_COMMIT_MESSAGE` flag to the `publish-gh-pages` command with the contents of `[skip ci]`. -e.g. +e.g. ```bash CUSTOM_COMMIT_MESSAGE="[skip ci]" \ yarn run publish-gh-pages # or `npm run publish-gh-pages` ``` -- Alternatively you can work around this by creating a basic Circle CI config with the following contents: +- Alternatively you can work around this by creating a basic CircleCI config with the following contents: ```yaml -# Circle CI 2.0 Config File +# CircleCI 2.0 Config File # This config file will prevent tests from being run on the gh-pages branch. version: 2 jobs: diff --git a/website-1.x/versioned_docs/version-1.7.0/getting-started-publishing.md b/website-1.x/versioned_docs/version-1.7.0/getting-started-publishing.md index 12cf33f79b..78bb0c9619 100644 --- a/website-1.x/versioned_docs/version-1.7.0/getting-started-publishing.md +++ b/website-1.x/versioned_docs/version-1.7.0/getting-started-publishing.md @@ -100,16 +100,16 @@ However, you can automate the publishing process with continuous integration (CI ## Automating Deployments Using Continuous Integration -Continuous integration (CI) services are typically used to perform routine tasks whenever new commits are checked in to source control. These tasks can be any combination of running unit tests and integration tests, automating builds, publishing packages to NPM, and yes, deploying changes to your website. All you need to do to automate deployment of your website is to invoke the `publish-gh-pages` script whenever your docs get updated. In the following section we'll be covering how to do just that using [Circle CI](https://circleci.com/), a popular continuous integration service provider. +Continuous integration (CI) services are typically used to perform routine tasks whenever new commits are checked in to source control. These tasks can be any combination of running unit tests and integration tests, automating builds, publishing packages to NPM, and yes, deploying changes to your website. All you need to do to automate deployment of your website is to invoke the `publish-gh-pages` script whenever your docs get updated. In the following section we'll be covering how to do just that using [CircleCI](https://circleci.com/), a popular continuous integration service provider. -### Using Circle CI 2.0 +### Using CircleCI 2.0 If you haven't done so already, you can [setup CircleCI](https://circleci.com/signup/) for your open source project. Afterwards, in order to enable automatic deployment of your site and documentation via CircleCI, just configure Circle to run the `publish-gh-pages` script as part of the deployment step. You can follow the steps below to get that setup. 1. Ensure the GitHub account that will be set as the `GIT_USER` has `write` access to the repository that contains the documentation, by checking `Settings | Collaborators & teams` in the repository. 1. Log into GitHub as the `GIT_USER`. 1. Go to https://github.com/settings/tokens for the `GIT_USER` and generate a new [personal access token](https://help.github.com/articles/creating-a-personal-access-token-for-the-command-line/), granting it full control of private repositories through the `repository` access scope. Store this token in a safe place, making sure to not share it with anyone. This token can be used to authenticate GitHub actions on your behalf in place of your GitHub password. -1. Open your Circle CI dashboard, and navigate to the Settings page for your repository, then select "Environment variables". The URL looks like https://circleci.com/gh/ORG/REPO/edit#env-vars, where "ORG/REPO" should be replaced with your own GitHub organization/repository. +1. Open your CircleCI dashboard, and navigate to the Settings page for your repository, then select "Environment variables". The URL looks like https://circleci.com/gh/ORG/REPO/edit#env-vars, where "ORG/REPO" should be replaced with your own GitHub organization/repository. 1. Create a new environment variable named `GITHUB_TOKEN`, using your newly generated access token as the value. 1. Create a `.circleci` directory and create a `config.yml` under that directory. 1. Copy the text below into `.circleci/config.yml`. @@ -159,23 +159,23 @@ Make sure to replace all `<....>` in the `command:` sequence with appropriate va Now, whenever a new commit lands in `master`, CircleCI will run your suite of tests and, if everything passes, your website will be deployed via the `publish-gh-pages` script. -> If you would rather use a deploy key instead of a personal access token, you can by starting with the Circle CI [instructions](https://circleci.com/docs/1.0/adding-read-write-deployment-key/) for adding a read/write deploy key. +> If you would rather use a deploy key instead of a personal access token, you can by starting with the CircleCI [instructions](https://circleci.com/docs/1.0/adding-read-write-deployment-key/) for adding a read/write deploy key. ### Tips & Tricks -When initially deploying to a `gh-pages` branch using Circle CI, you may notice that some jobs triggered by commits to the `gh-pages` branch fail to run successfully due to a lack of tests (This can also result in chat/slack build failure notifications). +When initially deploying to a `gh-pages` branch using CircleCI, you may notice that some jobs triggered by commits to the `gh-pages` branch fail to run successfully due to a lack of tests (This can also result in chat/slack build failure notifications). You can work around this easily by: - Setting the environment variable `CUSTOM_COMMIT_MESSAGE` flag to the `publish-gh-pages` command with the contents of `[skip ci]`. -e.g. +e.g. ```bash CUSTOM_COMMIT_MESSAGE="[skip ci]" \ yarn run publish-gh-pages # or `npm run publish-gh-pages` ``` -- Alternatively you can work around this by creating a basic Circle CI config with the following contents: +- Alternatively you can work around this by creating a basic CircleCI config with the following contents: ```yaml -# Circle CI 2.0 Config File +# CircleCI 2.0 Config File # This config file will prevent tests from being run on the gh-pages branch. version: 2 jobs: