Hosting Documentation

Package Guide と Doctests ページを通過した後、生成されたドキュメントをどこかにホストして、潜在的なユーザーが読むことができるようにする必要があります。このガイドでは、Travis CI ビルドサービスまたは GitHub Actions を使用して、生成された HTML ファイルをホストするための GitHub Pages とともに、パッケージのドキュメントの自動更新を設定する方法について説明します。これは、このパッケージが自分のドキュメントをホストするために使用しているのと同じアプローチです – あなたが現在読んでいるドキュメントです。

Overview

正しく設定されると、パッケージリポジトリに新しい更新をプッシュするたびに、次のことが発生します：

• ビルドボットは、"Test" ステージであなたのパッケージテストを起動して実行します。
• テストステージが完了した後、単一のボットが新しい「ドキュメント」ステージを実行し、ドキュメントをビルドします。
• ドキュメントが正常にビルドされると、ボットは生成されたHTMLページをGitHubにプッシュしようとします。

ホストされたドキュメントは、あなた（または他の貢献者）がプルリクエストを作成しても更新されないことに注意してください。更新は、トランクブランチ（通常は master または main）にマージするか、新しいタグをプッシュしたときにのみ表示されます。

次のセクションでは、ドキュメントビルドステージを実行するためにビルドサービスを構成する方法について説明します。一般的には、パッケージをテストしているのと同じサービスを選択するのが最も簡単です。deploydocsのdeploy_configキーワード引数でサービスを明示的に選択しない場合、Documenterは自動的に実行中のシステムを検出し、それを使用しようとします。

Travis CI

Travisに新しいビルドステージを追加したいことを伝えるために、既存の.travis.ymlファイルに以下を追加できます。以下のスニペットは単独では機能せず、完全なTravisファイルと一緒に使用する必要があることに注意してください。

jobs:
  include:
    - stage: "Documentation"
      julia: 1
      os: linux
      script:
        - julia --project=docs/ -e 'using Pkg; Pkg.develop(PackageSpec(path=pwd()));
                                               Pkg.instantiate()'
        - julia --project=docs/ docs/make.jl
      after_success: skip

julia: と os: のエントリは、ドキュメントが構築され、展開されるワーカーを決定します。上記の例では、したがって、Julia 1（最新の安定版）を実行しているLinuxワーカーからドキュメントを構築し、展開します。ビルドステージの設定方法についての詳細は、Build Stages のTravisマニュアルを参照してください。

script: セクションの3行は次のことを行います：

1. ドキュメントビルディング環境をインスタンス化します（すなわち、docs/Project.toml、以下を参照）。
2. ドキュメントビルド環境にパッケージをインストールします。
3. docs/make.jl スクリプトを実行して、ドキュメントをビルドおよびデプロイします。

Authentication: SSH Deploy Keys

生成されたドキュメントをTravisからプッシュするには、デプロイキーを追加する必要があります。デプロイキーは、生成されたドキュメントをビルダーからGitHubに安全にデプロイするために、単一のリポジトリへのプッシュアクセスを提供します。SSHキーは、DocumenterToolsパッケージのDocumenterTools.genkeysを使用して生成できます。

DocumenterToolsをインストールして読み込むには、次のコマンドを実行します。

pkg> add DocumenterTools

julia> using DocumenterTools

次に、次のように DocumenterTools.genkeys 関数を呼び出します:

julia> using DocumenterTools
julia> DocumenterTools.genkeys(user="MyUser", repo="MyPackage.jl")

MyPackageは、デプロイキーを作成したいパッケージの名前で、MyUserはあなたのGitHubユーザー名です。キーワード引数はオプションであり、省略することができます。

パッケージが ] dev MyPackage で開発モードでチェックアウトされている場合、次のように DocumenterTools.genkeys を使用することもできます:

julia> using MyPackage
julia> DocumenterTools.genkeys(MyPackage)

MyPackageは、デプロイキーを作成したいパッケージです。出力は以下のテキストに似たものになります：

[ Info: add the public key below to https://github.com/USER/REPO/settings/keys
      with read/write access:

[SSH PUBLIC KEY HERE]

[ Info: add a secure environment variable named 'DOCUMENTER_KEY' to
  https://travis-ci.com/USER/REPO/settings with value:

[LONG BASE64 ENCODED PRIVATE KEY]

指示に従ってください。具体的には：

1. GitHubリポジトリの設定ページに公開SSHキーを追加するには、提供された.../settings/keysリンクに従ってください。Add deploy keyをクリックし、タイトルとしてdocumenterを入力し、公開キーをKeyフィールドにコピーします。Documenterが生成されたドキュメントをリポジトリにコミットできるようにするには、Allow write accessをチェックしてください。

2. 次に、提供されたリンクを使用してTravis設定ページに長い秘密鍵を追加します。鍵をコピーする際には空白を含めないように注意してください。Environment Variablesセクションに、名前がDOCUMENTER_KEYのキーを追加し、出力された値を設定します。ビルドログに表示されるように変数を設定しないでください。その後、Addをクリックします。

   Security warning

   このキーが隠されていることを再確認してください。特に、Travis CIの設定では、「ビルドログに値を表示」オプションは変数に対してOFFにする必要があります。そうしないと、テストが実行される際に印刷されてしまいます。このbase64エンコードされた文字列には、リポジトリへの完全な書き込みアクセスを与える暗号化されていないプライベートキーが含まれているため、安全に保管する必要があります。また、この変数をテストで公開したり、それを含むコードをマージしたりしないようにしてください。Travisの環境変数については、Travis User Documentationを参照してください。

GitHub Actions

GitHub Actionsからドキュメントビルドを実行するには、次の内容で.github/workflows/documentation.ymlという新しいワークフロー構成ファイルを作成します:

name: Documentation

on:
  push:
    branches:
      - master # update to match your development branch (master, main, dev, trunk, ...)
    tags: '*'
  pull_request:

jobs:
  build:
    # These permissions are needed to:
    # - Deploy the documentation: https://documenter.juliadocs.org/stable/man/hosting/#Permissions
    # - Delete old caches: https://github.com/julia-actions/cache#usage
    permissions:
      actions: write
      contents: write
      pull-requests: read
      statuses: write
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: julia-actions/setup-julia@v2
        with:
          version: '1'
      - uses: julia-actions/cache@v2
      - name: Install dependencies
        shell: julia --color=yes --project=docs {0}
        run: |
          using Pkg
          Pkg.develop(PackageSpec(path=pwd()))
          Pkg.instantiate()
      - name: Build and deploy
        run: julia --color=yes --project=docs docs/make.jl
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} # If authenticating with GitHub Actions token
          DOCUMENTER_KEY: ${{ secrets.DOCUMENTER_KEY }} # If authenticating with SSH deploy key

これにより、Juliaがインストールされ、リポジトリの正しいコミットがチェックアウトされ、ドキュメントのビルドが実行されます。 julia-version:, julia-arch: および os: エントリは、ドキュメントがビルドおよびデプロイされる環境を決定します。上記の例では、Julia 1を実行しているUbuntuワーカーからドキュメントがビルドおよびデプロイされます。

run: セクションの行にあるコマンドは、前のセクションと同様に Travis のためのものです。

name: TagBot
on:
  issue_comment:
    types:
      - created
  workflow_dispatch:
jobs:
  TagBot:
    if: github.event_name == 'workflow_dispatch' || github.actor == 'JuliaTagBot'
    runs-on: ubuntu-latest
    steps:
      - uses: JuliaRegistries/TagBot@v1
        with:
          token: ${{ secrets.GITHUB_TOKEN }}
          ssh: ${{ secrets.DOCUMENTER_KEY }}

Authentication: GITHUB_TOKEN

GitHub Actionsから実行する際には、the GitHub Actions authentication token (GITHUB_TOKEN)を使用して認証することが可能です。これは、追加することによって行われます。

GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

previous sectionに示されているように、設定ファイルに。

Authentication: SSH Deploy Keys

SSHデプロイキーを使用して認証することも可能です。これは、SSH Deploy Keys section for Travis CIで説明されている通りです。キーは同じ方法で生成でき、その後、エンコードされたキーをリポジトリ設定の秘密環境変数として設定します。また、ドキュメントビルディングワークフローでキーを利用できるようにするために、次のように追加する必要があります。

DOCUMENTER_KEY: ${{ secrets.DOCUMENTER_KEY }}

設定ファイルに、previous sectionに示されているように追加します。詳細については、GitHubのマニュアルを参照してください。Encrypted secrets

Permissions

以下の GitHub Actions job or workflow permissions は、 deploydocs を正常に使用するために必要です。

permissions:
  contents: write  # Required when authenticating with `GITHUB_TOKEN`, not needed when authenticating with SSH deploy keys
  pull-requests: read  # Required when using `push_preview=true`
  statuses: write  # Optional, used to report documentation build statuses

Add code coverage from documentation builds

ドキュメントのデプロイ中に実行されるコードがCodecovによってカバーされるようにしたい場合は、ワークフロー構成ファイルのドキュメント部分の最後を編集して、docs/make.jlが--code-coverage=userフラグで実行され、カバレッジレポートがCodecovにアップロードされるようにします：

      - run: julia --project=docs --code-coverage=user docs/make.jl
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          DOCUMENTER_KEY: ${{ secrets.DOCUMENTER_KEY }}
      - uses: julia-actions/julia-processcoverage@v1
      - uses: codecov/codecov-action@v5

docs/Project.toml

ドキュメントビルド環境 docs/Project.toml には、Documenter およびあなたのパッケージが持つ可能性のある他のドキュメントビルド依存関係が含まれています。Documenter が唯一の依存関係である場合、Project.toml には以下を含める必要があります：

[deps]
Documenter = "e30172f5-a6a5-5a46-863b-614d45cd2de4"

[compat]
Documenter = "1.9"

注意してください。Project.tomlファイルに上記のような[compat]セクションを持つことが推奨されます。これにより、ビルドが実行される際にインストールされるDocumenterのバージョンが制限されます。これは、新しいメジャーリリースのDocumenterによる破壊的変更のために、ビルドが突然失敗しないようにするためです。ただし、これによりDocumenterの更新が自動的に行われなくなるため、Documenterのメジャーバージョンを自分でアップグレードする必要があります。

The deploydocs Function

現在、あなたの docs/make.jl ファイルにはおそらく次の内容しか含まれていません。

using Documenter, PACKAGE_NAME

makedocs()

このファイルの makedocs の後に、ドキュメントを gh-pages ブランチにデプロイする追加の関数呼び出しを追加する必要があります。ファイルの最後に以下を追加してください：

deploydocs(
    repo = "github.com/USER_NAME/PACKAGE_NAME.jl.git",
)

USER_NAME と PACKAGE_NAME は適切な名前に設定する必要があります。repo はプロトコルを指定してはいけません。つまり、https:// や git@ で始めてはいけません。

deploydocs 関数のドキュメントを参照して、詳細をご確認ください。

.gitignore

あなたのパッケージの .gitignore ファイルに以下を追加してください。

docs/build/

これらは、生成されたコンテンツをリポジトリにコミットしないようにするために必要です。

gh-pages Branch

デフォルトでは、Documenterはドキュメントをgh-pagesブランチにプッシュします。ブランチが存在しない場合は、deploydocsによって自動的に作成されます。存在する場合は、Documenterは単にビルドされたドキュメントを追加のコミットとして追加します。Documenterが既存のコンテンツを警告なしに上書きする可能性があることを認識しておくべきです。

もし手動で gh-pages ブランチを作成したい場合は、次のコマンドを実行できます creating an "orphan" branch, with the git checkout --orphan option。

あなたはまた、gh-pages branch と / (root) が選択されていることを確認する必要があります。そうしないと、GitHubは実際にコンテンツをウェブサイトとして提供しません。

Cleaning up gh-pages

gh-pages ブランチは非常に大きくなる可能性があります。特に、各プルリクエストのためにドキュメントをビルドするために push_preview が有効になっている場合はなおさらです。ブランチをクリーンアップし、古いドキュメントのプレビューを削除するために、以下のような GitHub Actions ワークフローを使用できます。

name: Doc Preview Cleanup

on:
  pull_request:
    types: [closed]

# Ensure that only one "Doc Preview Cleanup" workflow is force pushing at a time
concurrency:
  group: doc-preview-cleanup
  cancel-in-progress: false

jobs:
  doc-preview-cleanup:
    runs-on: ubuntu-latest
    permissions:
      contents: write
    steps:
      - name: Checkout gh-pages branch
        uses: actions/checkout@v4
        with:
          ref: gh-pages
      - name: Delete preview and history + push changes
        run: |
          if [ -d "${preview_dir}" ]; then
              git config user.name "Documenter.jl"
              git config user.email "documenter@juliadocs.github.io"
              git rm -rf "${preview_dir}"
              git commit -m "delete preview"
              git branch gh-pages-new "$(echo "delete history" | git commit-tree "HEAD^{tree}")"
              git push --force origin gh-pages-new:gh-pages
          fi
        env:
          preview_dir: previews/PR${{ github.event.number }}

このワークフローは、CliMA/ClimaTimeSteppers.jl (Apache License 2.0) に基づいています。

permissions: の行は、 GitHub Docs に記載されています。代替手段として、リポジトリ設定で GitHub ワークフローに書き込み権限を与えることができます。例: https://github.com/<USER>/<REPO>.jl/settings/actions。

Woodpecker CI

Woodpecker CIからドキュメントビルドを実行するには、選択したフォージ（GitHub、GitLab、Codeberg、または任意のGiteaインスタンス）からアクセストークンを作成する必要があります。このアクセストークンは、project_access_tokenという名前のシークレットとしてWoodpecker CIに追加する必要があります。大文字小文字は区別されませんので、これはパイプラインに大文字の環境変数として渡されます。次に、以下の内容を持つ新しいパイプライン構成ファイル.woodpecker.ymlを作成します。

• ウッドペッカー 0.15.x およびプレ1.0.0

  pipeline:
      docs:
      when:
          branch: main  # update to match your development branch
      image: julia
      commands:
          - julia --project=docs/ -e 'using Pkg; Pkg.develop(PackageSpec(path=pwd())); Pkg.instantiate()'
          - julia --project=docs/ docs/make.jl
      secrets: [ project_access_token ]  # access token is a secret
  

• ウッドペッカー 1.0.x 以降

  steps:
      docs:
      when:
          branch: main  # update to match your development branch
      image: julia
      commands:
          - julia --project=docs/ -e 'using Pkg; Pkg.develop(PackageSpec(path=pwd())); Pkg.instantiate()'
          - julia --project=docs/ docs/make.jl
      secrets: [ project_access_token ]  # access token is a secret
  

これは、DockerからJuliaのイメージを取得し、commands:から以下のコマンドを実行します。これにより、開発のためにプロジェクトがインスタンス化され、その後make.jlファイルが実行され、ドキュメントがビルドされてデプロイされます。デフォルトではpagesブランチにデプロイされますが、これを他のものに変更することもできます。例えば、GitHubの場合は→ gh-pages、Codebergの場合は→ pagesです。

Documentation Versions

デフォルトでは、ドキュメントは次のように展開されます：

• <tag_prefix>vX.Y.Zというタグのために構築されたドキュメントは、tag_prefixキーワードによって決定されるフォルダーvX.Y.Zに保存されます。これはdeploydocs（デフォルトでは""）です。

• devbranch ブランチ（デフォルトは master）から構築されたドキュメントは、devurl キーワードによって決定されるフォルダーに保存されます。これは deploydocs（デフォルトは dev）です。

どのバージョンがバージョンセレクタに表示されるかは、versions 引数によって決まります deploydocs。非デフォルトの tag_prefix の使用例については、Deploying from a monorepo を参照してください。

カスタムドメインが使用されていない場合、ページは次の場所にあります:

https://USER_NAME.github.io/PACKAGE_NAME.jl/vX.Y.Z
https://USER_NAME.github.io/PACKAGE_NAME.jl/dev

デフォルトでは、Documenterは最新のリリースを指すstableというリンクを作成します。

https://USER_NAME.github.io/PACKAGE_NAME.jl/stable

このリンクを使用することをお勧めします。バージョン付きのリンクではなく、新しいリリースで更新されるためです。

ドキュメントが gh-pages ブランチにプッシュされたら、README.md に stable （おそらく dev）ドキュメントのURLを指すリンクを追加する必要があります。TravisやAppVeyorのビルドステータスやコードカバレッジに使用される「バッジ」を利用することは一般的な慣習です。次の内容をパッケージの README.md に追加するだけで十分です：

[![](https://img.shields.io/badge/docs-stable-blue.svg)](https://USER_NAME.github.io/PACKAGE_NAME.jl/stable)
[![](https://img.shields.io/badge/docs-dev-blue.svg)](https://USER_NAME.github.io/PACKAGE_NAME.jl/dev)

PACKAGE_NAME と USER_NAME はそれぞれの適切な値に置き換える必要があります。画像の色とテキストは、shields.io に記載されているように docs-stable-blue を変更することで変更できますが、パッケージの著者は、複数のパッケージの README ファイルでドキュメントリンクを見つけやすくするために、この標準に従うことを推奨します。

Fixing broken release deployments

ある理由から、パッケージのタグ付きバージョンのドキュメントがデプロイに失敗し、修正にはソースコードの変更が必要になることがあります（例：誤って設定された make.jl）。しかし、登録されたタグは変更すべきではないため、修正を加えた元のタグ（例：v1.2.3）を単純に更新することはできません。

この状況では、修正を含むコミットのために同じバージョン番号を持つタグを手動で作成してプッシュできますが、ビルドメタデータも含めることができます（例：v1.2.3+doc1）。Gitにとって、これはまったく異なるタグであるため、何も干渉しません。しかし、Documenterがこのタグで実行されると、ビルドメタデータは無視され、ドキュメントはバージョンv1.2.3のものであるかのようにデプロイされます。

通常のタグビルドと同様に、Documenterを実行するCIがそのようなタグで実行されるように構成されていることを確認する必要があります（例えば、CIが実行されるブランチを制約する正規表現が十分に広いことなど）。

Deploying without the versioning scheme

Documenterは、前のセクションで説明したように、バージョンのサブフォルダーを無視してウェブサイトのルートに直接デプロイすることをサポートしています。これは、たとえばバージョン管理されていないプロジェクトにDocumenterを使用する場合に便利です。これを行うには、versions = nothingをdeploydocs関数に渡します。これで、ページは直接次の場所に見つかるはずです。

https://USER_NAME.github.io/PACKAGE_NAME.jl/

プレビュー ビルドはまだ previews サブフォルダーにデプロイされています。

Out-of-repo deployment

時々、gh-pages ブランチは、時間の経過とともに多くのコミットがあるため、または図やその他の大きなアーティファクトのために非常に大きくなることがあります。そのような場合、別のリポジトリの gh-pages にドキュメントをデプロイすることが有用です。以下の手順を使用して、「ソース」リポジトリのドキュメントを「ターゲット」リポジトリにデプロイできます。

1. DocumenterTools.genkeys()を実行して、キーのペアを生成します。
2. ターゲットリポジトリにデプロイキーを追加します
3. DOCUMENTER_KEY シークレットを"source" リポジトリに追加してください（ドキュメントワークフローを実行するリポジトリ）。
4. docs/make.jlを「target」リポジトリにデプロイするように適応させます:

# url of target repo
repo = "github.com/TargetRepoOrg/TargetRepo.git"

# You have to override the corresponding environment variable that
# deplodocs uses to determine if it is deploying to the correct repository.
# For GitHub, it's the GITHUB_REPOSITORY variable:
withenv("GITHUB_REPOSITORY" => repo) do
  deploydocs(repo=repo)
end

Deploying from a monorepo

Documenter.jlは、複数のパッケージ（潜在的にトップレベルのものを含む）を含むリポジトリに存在するパッケージのドキュメントを構築することをサポートしています。

以下は、次の構造を持つリポジトリのドキュメントを設定する例です：1つのトップレベルパッケージと2つのサブパッケージPackageA.jlおよびPackageB.jl：

.
├── README.md
├── docs
|   ├── make.jl
│   └── Project.toml
├── src/...
├── PackageA.jl
│   ├── docs
|   │   ├── make.jl
|   │   └── Project.toml
│   └── src/...
└── PackageB.jl
    ├── docs
    │   ├── make.jl
    │   └── Project.toml
    └── src/...

3つのそれぞれの make.jl スクリプトには、次のような deploydocs 設定が含まれている必要があります。

# In ./docs/make.jl
deploydocs(; repo = "github.com/USER_NAME/PACKAGE_NAME.jl.git",
            # ...any additional kwargs
            )

# In ./PackageA.jl/docs/make.jl
deploydocs(; repo = "github.com/USER_NAME/PACKAGE_NAME.jl.git",
             dirname="PackageA",
             tag_prefix="PackageA-",
             # ...any additional kwargs
             )

# In ./PackageB.jl/docs/make.jl
deploydocs(; repo = "github.com/USER_NAME/PACKAGE_NAME.jl.git",
             dirname="PackageB",
             tag_prefix="PackageB-",
             # ...any additional kwargs
             )

各パッケージのために別々のドキュメントを構築するには、各パッケージごとに3つの別々のビルドボット設定を作成します。使用するサービスに応じて、各 make.jl スクリプトを呼び出すセクションは適切に設定する必要があります。例えば、

# In the configuration file that builds docs for the top level package
run: julia --project=docs/ docs/make.jl

# In the configuration file that builds docs for PackageA.jl
run: julia --project=PackageA.jl/docs/ PackageA.jl/docs/make.jl

# In the configuration file that builds docs for PackageB.jl
run: julia --project=PackageB.jl/docs/ PackageB.jl/docs/make.jl

各サブパッケージのリリースは、同じプレフィックスでタグ付けされるべきです。つまり、v0.3.2（トップレベルパッケージ用）、PackageA-v0.1.2、および PackageB-v3.2+extra_build_tags です。これにより、バージョン付きのドキュメントデプロイメントがトリガーされます。Documentation Versions と同様に、カスタムドメインが使用されない限り、これらの3つの別々のページセットは次の場所にあります：

https://USER_NAME.github.io/PACKAGE_NAME.jl/vX.Y.Z
https://USER_NAME.github.io/PACKAGE_NAME.jl/dev
https://USER_NAME.github.io/PACKAGE_NAME.jl/stable  # Links to most recent top level version

https://USER_NAME.github.io/PACKAGE_NAME.jl/PackageA/vX.Y.Z
https://USER_NAME.github.io/PACKAGE_NAME.jl/PackageA/dev
https://USER_NAME.github.io/PACKAGE_NAME.jl/PackageA/stable  # Links to most recent PackageA version

https://USER_NAME.github.io/PACKAGE_NAME.jl/PackageB/vX.Y.Z
https://USER_NAME.github.io/PACKAGE_NAME.jl/PackageB/dev
https://USER_NAME.github.io/PACKAGE_NAME.jl/PackageB/stable  # Links to most recent PackageB version

相互に自動的に参照されることはありませんが、そのような参照は手動で追加することができます（例：PackageBのために構築されたドキュメントからhttps://USER_NAME.github.io/PACKAGE_NAME.jl/PackageA/stableにリンクすることによって）。

Deployment systems

Documenterは、上記のセクションで説明されているシステム以外のシステムを使用するようにカスタマイズすることが可能です。これは、deploy_configキーワード引数を使用してdeploydocsに設定（DeployConfig）を渡すことで行います。Documenterは、Travis、GitHubActions、GitLab、およびBuildkiteをネイティブにサポートしていますが、以下に説明するシンプルなインターフェースに従うことで、自分自身のものを簡単に定義することができます。

DeployConfig

Documenter.deploy_folder(cfg::DeployConfig; repo, devbranch, push_preview, devurl,
                         tag_prefix, kwargs...)

DeployDecision(; kwargs...)

Documenter.authentication_method(::DeployConfig)

Documenter.authenticated_repo_url(cfg::DeployConfig)

Documenter.documenter_key(cfg::DeployConfig)

Documenter.documenter_key_previews(cfg::DeployConfig)

Travis <: DeployConfig

GitHubActions <: DeployConfig

GitLab <: DeployConfig

Buildkite <: DeployConfig

Woodpecker <: DeployConfig

labels:
  platform: linux/amd64

steps:
  docs:
    when:
      branch:
        - main
    image: opensuse/tumbleweed
    commands:
      - zypper --non-interactive install openssh juliaup git
      - /usr/bin/julia --project=docs/ --startup-file=no --history-file=no -e "import Pkg; Pkg.instantiate()"
      - /usr/bin/julia --project=docs/ --startup-file=no --history-file=no -e docs/make.jl
    secrets: [ documenter_key, project_access_token ]

platforms: linux/amd64

pipeline:
  docs:
    when:
      branch:
        - main
    image: opensuse/tumbleweed
    commands:
      - zypper --non-interactive install openssh juliaup git
      - /usr/bin/julia --project=docs/ --startup-file=no --history-file=no -e "import Pkg; Pkg.instantiate()"
      - /usr/bin/julia --project=docs/ --startup-file=no --history-file=no -e docs/make.jl
    secrets: [ documenter_key, project_access_token ]