Githubアクションによる記事の連続配信

私は、連続配達の大きい支持者です:価値を配達することは、ルーチンで、速くて、簡単でなければなりません.私は最近、同様に私の執筆にその考え方を適用しましたGithub Actions , と.

でもどうして?
書くための私の典型的なワークフローは、テキストファイル(通常VimまたはVSCode)でブレーンストーミングを開始することです、そして徐々に徐々に書くことの一貫した作品に.私は、フォーマットが単純に手でするのが簡単であるので、Markdownで書くのを好みます、そして、ちょっとHTMLとしてレンダリングするか、ちょうどGoogleドキュメントにペーストします.
出版部は、通常、私がぎょっとされるところです.私は、正しいプラットホームが何であったかについて、私自身と議論して、次に、リンクが働いたようにするために再フォーマットしなければなりません.何を修正する必要がある場合は?プロセスを繰り返します.
多くの場合、私はちょうど作品には、プロセスが迷惑だった作業を停止します.これは、連続配達が解決することができた問題のような感じがしました.

Githubアクションを持つライターのCI/CD
私の通常の執筆ワークフローは、Markdownとテキストファイルから始まるので、変更がGitレポで私の文書を保つために必要でありませんでした.実際、私は既に空のレポをすでに持っていました.

Githubアクションの作成
私は、出版のために私自身のGitHubアクションを作成することは不必要だった正面を認めます、そして、私は学習運動としてそれをしました.既にan action to publish to dev.to , しかし、JavaScriptはあまり得意ではなく、より良いアクションを理解したかったので、私は自分自身を構築しました.muncus/devto-publish-action .
Golangのコードは、dev . to APIを呼び出すためにはかなり簡単ですし、私はDockerfileとGithubアクションYAMLファイルとのより多くの時間を過ごした.
バイナリは基本的に3つの入力を取ります:マークダウンファイルでいっぱいのディレクトリ、dev . to APIキー、およびJIDファイルで、記事IDを保存します(変更があるとき、同じファイルを再公開することができます).
これらの引数はinputs セクションaction.yaml , で参照args セクション.
余分なボーナスとして、私はアクションのためのGOコードを構築し、テストするワークフローを追加しました.github/workflows/build-go.yml . このワークフローは、チュートリアル(しかし、私はソースを忘れました)からとられます.
今私たちのアクションレポが作成され、公開され、それは別のワークフローを作成することによって、我々の執筆レポでそれを使用する時です.

ワークフローからのアクションの呼び出し
記事を出版するための完全なワークフローには3つの手順があります.

私のポストを含んでいる私の個人的なレポをチェックしてください

記事を発表する

更新ids.json 新しく公開された記事IDで、私は最初の出版の後、ポストを編集することができます.

秘密の設定
我々はこのワークフローを設定する前に、秘密の情報の2つのキーを格納するための安全な場所が必要です.
Github Secrets これに最適です.

私のプライベートリポジトリを読むGithub資格情報

個人的なアクセストークンを作成しMY_GH_PAT .

私に代わって掲示するために.

これらは"dev API keys "の下に作成されます.

この秘密はDEVTO_API_TOKEN

これらの秘密を作成すると、我々は我々の貴重な資格情報を公開せずに参照するワークフローを作成することができます!各ステップを個別に見てみましょう.

ステップ1:プライベートレポをチェックアウト

    - name: Check out repo
      uses: actions/checkout@v2
      with:
        token: "${{ secrets.MY_GH_PAT }}"

これは、組み込みのアクションを使用してtoken 入力.私はプライベートレポで私の書き込みを維持するので、我々はアクセストークンを指定する必要があります.

ステップ2:私たちのカスタムアクションで公開

    - name: Publish to Dev.to
      uses: muncus/devto-publish-action@release/v1
      with:
        directory: "$GITHUB_WORKSPACE/dev.to/"
        api-key: "${{ secrets.DEVTO_API_TOKEN }}"
        state-file: "$GITHUB_WORKSPACE/ids.json"

これは私のカスタムアクションを参照し、必要な入力を提供します.注意$GITHUB_WORKSPACE 前のステップでチェックアウトしたrepoのベースディレクトリである組み込み環境変数です.

ステップ3:ローカルの変更とPRを行う
私のパブリッシングアクションが実行されると、それは“ファイルを”ファイル名をマップに更新します.これは、新しい記事が追加された後、ローカルの変更があることを意味します.これらの変更を保存するには、これらのローカル変更からプル要求を作成する必要があります.

    - name: Create PR to update state file
      uses: peter-evans/create-pull-request@v3
      with:
        title: "[CI] Update state file with published article ids"
        reviewers: ${{ github.actor }}
        token: "${{ secrets.MY_GH_PAT }}"
        base: master
        branch: "ci/state-file-update"

多くの選択肢がありますpeter-evans/create-pull-request アクションは、ここで使用しているものを実行できます.

title : 完全に化粧品です、しかし、私が彼らが私のCIシステムからいるということを知っているとき、これは速く私がprsを承認するのを助けます.

reviewers : 誰でも、新しい記事を押した人がPRを承認する責任があると明らかにするために、彼らは校閲者としてリストされます.

token : これは上に作成したGithubアクセストークンです.この個人的なレポで私の資格情報を使用しているので、すべてのこれらのprsは、彼らが私によって作られたように見えます.それは共有レポのための理想的ではなく、私のニーズに最適です.

base : 我々が我々が比較しているものであるように、我々は出版にマスターをチェックします.

branch : 安定したPRブランチ名を使用すると、マージがより簡単になり、新しいファイルを発行する前に以前のPRを承認することを忘れた場合、状態ファイルに複数の変更を“スタックアップ”するのに役立ちます.

結論
私の経験では、アクション開発プロセスの最も困難な部分は、YAML「正しい」を得るために必要な試行錯誤だった.DockerFileの改良の余地はまだあります.そして、私は、各々の記事出版にもう30秒を保存するために、予め構築されたイメージを使用することができました.しかし、それはコードの代わりに散文を書くことを私たちに戻すのに十分よく働きます.
私はあなたが非伝統的な方法でGithubアクションを使用するように刺激を願っています!

付録:フルワークフロー

name: Publish
# Only trigger this workflow on master, and a feature branch specifically for testing the workflow.
on:
  push:
    branches: [ master, ci-action ]

jobs:
  build:
    name: Publish
    runs-on: ubuntu-latest
    steps:
    # First, check out the private repo.
    - name: Check out repo
      uses: actions/checkout@v2
      with:
        token: "${{ secrets.MY_GH_PAT }}"
    # Then publish articles.
    - name: Publish to Dev.to
      uses: muncus/devto-publish-action@release/v1
      with:
        directory: "$GITHUB_WORKSPACE/dev.to/"
        api-key: "${{ secrets.DEVTO_API_TOKEN }}"
        state-file: "$GITHUB_WORKSPACE/ids.json"
    # Last, update the state file by making a PR.
    - name: Create PR to update state file
      uses: peter-evans/create-pull-request@v3
      with:
        title: "[CI] Update state file with published article ids"
        reviewers: ${{ github.actor }}
        token: "${{ secrets.MY_GH_PAT }}"
        base: master
        branch: "ci/state-file-update"