next

Translate

Publishing your site

Agora você já deve ter um site pronto rodando localmente. Assim que você tiver terminado de personalizar ele para ficar nos trinques, é hora de publicá-lo. O Docusaurus gera um site estático HTML prontinho para ser servido pelo seu servidor ou solução de hospedagem favorito.

Gerando páginas estáticas HTML

Para criar uma versão estática do seu site, execute o seguinte script no diretório website:

yarn run build # ou `npm run build`

Isso vai gerar um diretório build dentro do diretório website contendo os arquivos .html da sua documentação e de outras páginas incluídas em pages.

Hospedando páginas estáticas HTML

Neste ponto, você já pode pegar todos os arquivos dentro do diretório website/build e copiar eles diretamente para o diretório html do seu servidor web favorito.

For example, both Apache and Nginx serve content from /var/www/html by default. Com isso dito, escolher onde você vai hospedar seu site está fora do escopo do Docusaurus.

Ao servir o site a partir de seu próprio servidor web, certifique-se de que ele esteja servindo os arquivos de assets com os cabeçalhos HTTP adequados. Arquivos CSS devem ser servidos com o cabeçalho de content-type como text/css. In the case of Nginx, this would mean setting include /etc/nginx/mime.types; in your nginx.conf file. See this issue for more info.

Hospedando em um serviço:

Using Vercel

Deploying your Docusaurus project to Vercel will provide you with various benefits in the areas of performance and ease of use.

Most importantly, however, deploying a Docusaurus project only takes a couple of seconds:

  1. First, install their command-line interface:
npm i -g vercel
  1. Run a single command inside the root directory of your project:
vercel

That's all. Your docs will automatically be deployed.

Note that the directory structure Now supports is slightly different from the default directory structure of a Docusaurus project - The docs directory has to be within the website directory, ideally following the directory structure in this example. You will also have to specify a customDocsPath value in siteConfig.js. Take a look at the now-examples repository for a Docusaurus project.

Usando o GitHub Pages

Docusaurus was designed to work well with one of the most popular hosting solutions for open source projects: GitHub Pages.

Deploying to GitHub Pages

  1. Docusaurus supports deploying as project pages or user/organization pages, your code repository does not even need to be public.

Mesmo que seu repositório seja privado, qualquer coisa publicada em uma branch gh-pages será pública.

Note: When you deploy as user/organization page, the publish script will deploy these sites to the root of the master branch of the username.github.io repo. Nesse caso, observe que você vai querer ter a infraestrutura do Docusaurus, sua documentação, etc. either in another branch of the username.github.io repo (e.g., maybe call it source), or in another, separate repo (e.g. in the same as the documented source code).

  1. You will need to modify the file website/siteConfig.js and add the required parameters.
NomeDescrição
organizationNameO usuário ou organização que é dona do repositório. If you are the owner, then it is your GitHub username. In the case of Docusaurus, that would be the "facebook" GitHub organization.
projectNameO nome do repositório do seu projeto no GitHub. For example, the source code for Docusaurus is hosted at https://github.com/facebook/docusaurus, so our project name, in this case, would be "docusaurus".
urlYour website's URL. For projects hosted on GitHub pages, this will be "https://username.github.io"
baseUrlBase URL for your project. For projects hosted on GitHub pages, it follows the format "/projectName/". For https://github.com/facebook/docusaurus, baseUrl is /docusaurus/.
 
const siteConfig = {
  ...
  url: 'https://__userName__.github.io', // Your website URL
  baseUrl: '/testProject/',
  projectName: 'testProject',
  organizationName: 'userName'
  ...
}

In case you want to deploy as a user or organization site, specify the project name as <username>.github.io or <orgname>.github.io. E.g. If your GitHub username is "user42" then user42.github.io, or in the case of an organization name of "org123", it will be org123.github.io.

Note: Not setting the url and baseUrl of your project might result in incorrect file paths generated which can cause broken links to assets paths like stylesheets and images.

Por mais que recomendemos configurar o projectName e o organizationName no siteConfig.js, você também pode usar as variáveis de ambiente ORGANIZATION_NAME e PROJECT_NAME.

  1. Now you have to specify the git user as an environment variable, and run the script publish-gh-pages
NomeDescrição
GIT_USERThe username for a GitHub account that has to commit access to this repo. For your repositories, this will usually be your own GitHub username. O GIT_USER especificado precisa ter acesso de push no repositório especificado pela combinação de organizationName e projectName.

Para rodar o script diretamente da linha de comando, você pode usar o seguinte comando, preenchendo os valores de parâmetros conforme apropriado.

Bash

GIT_USER=<GIT_USER> \
  CURRENT_BRANCH=master \
  USE_SSH=true \
  yarn run publish-gh-pages # ou `npm run publish-gh-pages`

Windows

cmd /C "set "GIT_USER=<GIT_USER>"&& set CURRENT_BRANCH=master && set USE_SSH=true && yarn run publish-gh-pages"

Há também dois parâmetros opcionais que são definidos como variáveis de ambiente:

NomeDescrição
USE_SSHSe definida como true, a conexão ao repositório do GitHub será feita por meio de SSH, ao invés de HTTPS. HTTPS é o padrão se essa variável não for definida.
CURRENT_BRANCHA branch que contém as alterações na documentação mais recentes que serão publicadas. Geralmente, essa branch será a master, mas poderia ser qualquer branch (padrão ou não) exceto pela gh-pages. Se nada for definido para essa variável, então a branch atual será usada.

Caso enfrente problemas relacionados a chaves SSH, visite a documentação de autenticação do GitHub.

Agora você já deve ser capaz de abrir seu site visitando o URL dele no GitHub Pages, o qual deve ser algo como https://nome-de-usuario.github.io/projectName, ou um domínio personalizado, caso você tenha configurado assim. For example, Docusaurus' own GitHub Pages URL is https://facebook.github.io/Docusaurus because it is served from the gh-pages branch of the https://github.com/facebook/docusaurus GitHub repository. However, it can also be accessed via https://docusaurus.io/, via a generated CNAME file which can be configured via the cname siteConfig option.

Recomendamos fortemente que você leia a documentação do GitHub Pages para saber mais sobre como essa solução de hospedagem funciona.

Você pode executar o comando acima a qualquer momento que você atualizar sua documentação e desejar publicar as alterações no seu site. Executar o script manualmente pode funcionar bem para sites onde a documentação raramente muda e não seja muito inconveniente lembrar de publicar as alterações manualmente.

No entanto, você pode automatizar o processo de publicação com integração contínua (CI).

Automatizando deploys usando integração contínua

Serviços de integração contínua (CI) são normalmente usados para realizar tarefas de rotina sempre que novos commits são enviados para o controle de código fonte. Dentre essas tarefas estão a execução de testes unitários e de integração, a automatização de builds, a publicação de pacotes ao NPM e, sim, a implementação de alterações ao seu site. All you need to do to automate the 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, a popular continuous integration service provider.

Usando CircleCI 2.0

Se ainda não tiver o feito, você pode configurar o CircleCI para seu projeto de código aberto. Depois disso, para poder fazer o deploy automático do seu site e documentação via CircleCI, basta configurar o Circle para executar o script publish-gh-pages como parte do processo de deploy. Você pode seguir este passo-a-passo para configurar certinho:

  1. Tenha certeza que a conta do GitHub que vai ser definida como GIT_USER tem acesso de escrita (write) ao repositório que contém a documentação. Você pode ver isso em Settings | Collaborators & teams no repositório.
  2. Faça login no GitHub como o GIT_USER.
  3. Vá para https://github.com/settings/tokens como o GIT_USER e gere um novo token de acesso pessoal, concedendo a ele controle total sobre repositórios privados através do escopo de acesso repository. Guarde este token em um lugar seguro, e tenha certeza de não compartilhar ele com ninguém. Este token pode ser usado para autenticar e realizar ações em seu nome, como se fosse a sua senha do GitHub.
  4. Open your CircleCI dashboard, and navigate to the Settings page for your repository, then select "Environment variables". O URL é algo como https://circleci.com/gh/ORG/REPO/edit#env-vars, onde "ORG/REPO" deve ser substituído pela sua própria organização/repositório do seu GitHub.
  5. Crie uma nova variável de ambiente chamada GITHUB_TOKEN, usando seu token de acesso recém-criado como o valor dela.
  6. Crie um diretório .circleci e crie um arquivo config.yml dentro dele.
  7. Copie o texto abaixo para o .circleci/config.yml.
# If you only want the circle to run on direct commits to master, you can uncomment this out
# and uncomment the filters: *filter-only-master down below too
#
# aliases:
#  - &filter-only-master
#    branches:
#      only:
#        - master

version: 2
jobs:
  deploy-website:
    docker:
      # specify the version you desire here

      - image: circleci/node:8.11.1

    steps:

      - checkout
      - run:
          name: Deploying to GitHub Pages
          command: |
            git config --global user.email "<GITHUB_USERNAME>@users.noreply.github.com"
            git config --global user.name "<YOUR_NAME>"
            echo "machine github.com login <GITHUB_USERNAME> password $GITHUB_TOKEN" > ~/.netrc
            cd website && yarn install && GIT_USER=<GIT_USER> yarn run publish-gh-pages

workflows:
  version: 2
  build_and_deploy:
    jobs:

      - deploy-website:
#         filters: *filter-only-master

Não se esqueça de substituir todos os <....> na sequência command: com os valores adequados. Como <GIT_USER>, você pode definir uma conta do GitHub que tenha permissão de push na documentação do seu repositório do GitHub. Na maioria das vezes, <GIT_USER> e <GITHUB_USERNAME> serão a mesma coisa.

NÃO coloque o valor da variável $GITHUB_TOKEN no circle.yml. We already configured that as an environment variable back in Step 5.

Se você quiser usar SSH para a conexão com o seu repositório GitHub, você pode configurar USE_SSH=true. Dessa forma, o comando acima seria algo como: cd website && npm install && GIT_USER=<GIT_USER> USE_SSH=true npm run publish-gh-pages.

Unlike when you run the publish-gh-pages script manually when the script runs within the Circle environment, the value of CURRENT_BRANCH is already defined as an environment variable within CircleCI and will be picked up by the script automatically.

Agora, sempre que um novo commit pintar na branch master, o CircleCI vai rodar sua bateria de testes e, se tudo passar, seu site será publicado através do script publish-gh-pages.

If you would rather use a deploy key instead of a personal access token, you can by starting with the CircleCI instructions for adding a read/write deploy key.

Truques e dicas

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 by:

  • Setting the environment variable CUSTOM_COMMIT_MESSAGE flag to the publish-gh-pages command with the contents of [skip ci]. e.g.
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 CircleCI config with the following contents:
# CircleCI 2.0 Config File
# This config file will prevent tests from being run on the gh-pages branch.
version: 2
jobs:
  build:
    machine: true
    branches:
      ignore: gh-pages
    steps:
      - run: echo "Pulando testes na branch gh-pages"

Salve este arquivo como config.yml e coloque-o em um diretório .circleci dentro do seu diretório website/static.

Usando o Travis CI

  1. Vá para https://github.com/settings/tokens e gere um novo token de acesso pessoal
  2. Usando sua conta do GitHub, adicione o app Travis CI ao repositório que você deseja ativar.
  3. Abra seu painel do Travis CI. O URL é algo como https://travis-ci.com/NOME_USUARIO/REPO. Daí, em seu repositório, vá para More options > Setting e navegue até a seção Environment Variables.
  4. Crie uma nova variável de ambiente chamada GH_TOKEN com seu token recém-criado como seu valor. Depois, crie GH_EMAIL (seu endereço de e-mail) e GH_NAME (seu nome de usuário do GitHub).
  5. Crie um .travis.yml na raiz do seu repositório contendo o texto abaixo.
# .travis.yml
language: node_js
node_js:
  - '8'
branches:
  only:
    - master
cache:
  yarn: true
script:
  - git config --global user.name "${GH_NAME}"
  - git config --global user.email "${GH_EMAIL}"
  - echo "machine github.com login ${GH_NAME} password ${GH_TOKEN}" > ~/.netrc
  - cd website && yarn install && GIT_USER="${GH_NAME}" yarn run publish-gh-pages

Agora, sempre que um novo commit pintar na branch master, o Travis CI vai rodar sua bateria de testes e, se tudo passar, seu site será publicado através do script publish-gh-pages.

Using Azure Pipelines

  1. Sign Up at Azure Pipelines if you haven't already.
  2. Create an organization and within the organization create a project and connect your repository from GitHub.
  3. Go to https://github.com/settings/tokens and generate a new personal access token with repository scope.
  4. In the project page (which looks like https://dev.azure.com/ORG_NAME/REPO_NAME/_build) create a new pipeline with the following text. Also, click on edit and add a new environment variable named GH_TOKEN with your newly generated token as its value, then GH_EMAIL (your email address) and GH_NAME (your GitHub username). Make sure to mark them as secret. Alternatively, you can also add a file named azure-pipelines.yml at yout repository root.
# azure-pipelines.yml
trigger:
  - master

pool:
  vmImage: 'ubuntu-latest'

steps:

  - checkout: self
    persistCredentials: true

  - task: NodeTool@0
    inputs:
      versionSpec: '10.x'
    displayName: 'Install Node.js'

  - script: |
      git config --global user.name "${GH_NAME}"
      git config --global user.email "${GH_EMAIL}"
      git checkout -b master
      echo "machine github.com login ${GH_NAME} password ${GH_TOKEN}" > ~/.netrc
      cd website
      yarn install
      GIT_USER="${GH_NAME}" CURRENT_BRANCH=master yarn run publish-gh-pages
    env:
      GH_NAME: $(GH_NAME)
      GH_EMAIL: $(GH_EMAIL)
      GH_TOKEN: $(GH_TOKEN)
    displayName: 'yarn install and build'

Using Drone

  1. Create a new ssh key that will be the deploy key for your project.
  2. Name your private and public keys to be specific and so that it does not overwrite your other ssh keys.
  3. Go to https://github.com/USERNAME/REPO/settings/keys and add a new deploy key by pasting in our public key you just generated.
  4. Open your Drone.io dashboard and login. The URL looks like https://cloud.drone.io/USERNAME/REPO.
  5. Click on the repository, click on activate repository, and add a secret called git_deploy_private_key with your private key value that you just generated.
  6. Create a .drone.yml on the root of your repository with below text.
# .drone.yml
kind: pipeline
type: docker
trigger:
  event:
    - tag
- name: Website
  image: node
  commands:
    - mkdir -p $HOME/.ssh
    - ssh-keyscan -t rsa github.com >> $HOME/.ssh/known_hosts
    - echo "$GITHUB_PRIVATE_KEY > $HOME/.ssh/id_rsa"
    - chmod 0600 $HOME/.ssh/id_rsa
    - cd website
    - npm i
    - npm run publish-gh-pages
  environment:
    USE_SSH: true
    GIT_USER: $DRONE_COMMIT_AUTHOR
    GITHUB_PRIVATE_KEY: git_deploy_private_key

Now, whenever you push a new tag to github, this trigger will start the drone ci job to publish your website.

Hosting on Vercel

Deploying your Docusaurus project to Vercel will provide you with various benefits in the areas of performance and ease of use.

To deploy your Docusaurus project with a Vercel for Git Integration, make sure it has been pushed to a Git repository.

Import the project into Vercel using the Import Flow. During the import, you will find all relevant options preconfigured for you; however, you can choose to change any of these options, a list of which can be found here.

After your project has been imported, all subsequent pushes to branches will generate Preview Deployments, and all changes made to the Production Branch (commonly "main") will result in a Production Deployment.

Hospedando no Netlify

Siga estes passos para configurar seu site Docusaurus no Netlify:

  1. Selecione New site from Git

  2. Conecte ao provedor Git de sua preferência.

  3. Selecione a branch a ser publicada. A padrão é a master

  4. Configure as etapas do processo de build:

    • Como comando de build, insira: cd website; npm install; npm run build;
    • Como diretório de publicação: website/build/<nomeDoProjeto> (use o nomeDoProjeto que está lá no seu siteConfig)

  5. Clique em Deploy site

Você também pode configurar o Netlify para repetir esse processo a cada commit no seu repositório, ou apenas para commits na branch master.

Hosting on Render

Render offers free static site hosting with fully managed SSL, custom domains, a global CDN and continuous auto deploy from your Git repo. Deploy your app in just a few minutes by following these steps.

  1. Create a new Web Service on Render, and give Render's GitHub app permission to access your Docusaurus repo.

  2. Selecione a branch a ser publicada. The default is master.

  3. Enter the following values during creation.

FieldValue
EnvironmentStatic Site
Build Commandcd website; yarn install; yarn build
Publish Directorywebsite/build/<projectName>

projectName is the value you defined in your siteConfig.js.

javascript{7}
   const siteConfig = {
     // ...
     projectName: 'your-project-name',
     // ...

That's it! Your app will be live on your Render URL as soon as the build finishes.

Publicando no GitHub Enterprise

Publicar no GitHub Enterprise deve funcionar da mesma maneira que no GitHub.com; você só precisa identificar o host da organização no GitHub Enterprise.

NomeDescrição
GITHUB_HOSTO nome do host para o servidor GitHub Enterprise.

Altere o seu siteConfig.js para adicionar uma propriedade 'githubHost', que representa o nome do host no GitHub Enterprise. Como alternativa, você pode definir uma variável de ambiente GITHUB_HOST ao executar o comando de publicação.

← Creating your siteDocker →