Re:VIEW の textlint 環境を整える

 Zenn で GitHub 管理された記事投稿ができるようになり、GtiHub Actions で textlint をかける CI 環境を作りましたが、これを技術書典などの書籍作成用リポジトリにも設定したいと思います。

textlint 環境の構築

npm で textlint と Re:VIEW 用のプラグインをインストールします。

npm install textlint
npm install textlint-plugin-review
npm install textlint-rule-preset-ja-technical-writing
npm install textlint-rule-preset-ja-spacing
npm install textlint-filter-rule-allowlist

それぞれのリポジトリはこちら

https://github.com/textlint/textlint
https://github.com/orangain/textlint-plugin-review
https://github.com/textlint-ja/textlint-rule-preset-ja-technical-writing
https://github.com/textlint-ja/textlint-rule-preset-ja-spacing
https://github.com/textlint/textlint-filter-rule-allowlist

.textlintrc をルートに配置

  {
  "plugins": {
    "@textlint/markdown": {
      "extensions": [".md"]
    },
    "review-starter": {
      "extensions": [".re"]
    }
  },
  "rules": {
    "preset-ja-technical-writing": {
      "sentence-length": false
    },
    "preset-ja-spacing": {
      "ja-space-between-half-and-full-width": {
        space: "always",
        exceptPunctuation: true,
      },
      "ja-space-around-code": {
        "before": true,
        "after": true
      }
    }
  },
  "filters": {
      "allowlist": {
        "allow": [
          "/(.|)[0-9]+(ヶ|か)月/",
          "/(.|)[0-9,]+(分|つ|回|時)/",
        ]
      }
  }
}
  

.textlintrc を配置したら
npx textlint <path> で検証できます。

例）

npx textlint -f unix ci-dex/contents/*.re
/ci-dex/contents/c000-preface.re:10:39: 弱い表現: "思います" が使われています。 [Error/ja-technical-writing/ja-no-weak-phrase]
ci-dex/contents/c000-preface.re:29:7: 原則として、全角文字と半角文字の間にスペースを入れます。 [Error/ja-spacing/ja-space-between-half-and-full-width]

GitHub Actions の設定

reviewdog の textlint action があるのでそれを使うと簡単に対応できます。
https://github.com/tsuyoshicho/action-textlint
yaml は以下のようになります。

name: 'Run textlint with reviewdog'
on: [pull_request]
jobs:
  textlint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v1
      - name: textlint-books
        uses: tsuyoshicho/action-textlint@v1
        with:
          github_token: ${{ secrets.GITHUB_TOKEN }}
          reporter: github-pr-review
          textlint_flags: "."  
  

VS Code 環境の設定

vscode-textlint 拡張機能をインストールすると VS Code エディタ上で textlint の指摘を確認できます。

ただし、こちらの拡張機能と「Re:VIEW」拡張機能の相性が悪いようで、「Re:VIEW」拡張機能を有効にしていると textlint の指摘が出てこなくなるので注意してください。
（類似の「yet another Re:VIEW」「Re:VIEW Starter Syntax Highlight」でも同様）

textlint よりも Re:VIEW のシンタックスハイライトがあったほうが便利なので、結局 textlint は CI で確認するようにしました。

Re:VIEW Starter に対応する

自分が執筆する際は Re:VIEW ではなく Re:VIEW Starter を使用しているので、そちらの構文に対応した「textlint-plugin-review-starter」を作成し、リリースしています。
https://github.com/srz-zumix/textlint-plugin-review-starter
https://www.npmjs.com/package/textlint-plugin-review-starter

textlint-plugin-review と同様に npm install すれば使用できます。
textlint-plugin-review にはなかった $/| のフェンス記法と、インラインコマンドの入れ子に対応しています。
もちろん、Re:VIEW Starter 独自のフォーマットにも対応しています。

なにか不具合あれば issue に投げてくださいmm

今回は以上です。では。

PyPI のリリースを検知して Dockerhub の image を更新する

3rd party の PyPI パッケージのリリースがあったら、自動で Dockerhub のビルドをキックして、latest の更新とバージョンのタグ付けをするパイプラインを構築しました。

できたのはこちら。

https://hub.docker.com/r/srzzumix/lizard

https://github.com/srz-zumix/docker-lizard

パイプライン

PyPI release の RSS を使い、RPA（Integromat） で定期的に読み取り、更新があったら Dockerhub のビルドトリガー URL を POST します。

Dockerhub のビルドができたら、出来上がったイメージからバージョンを取得してタグ付けをしています。

Dockerhub のビルドでは Dockerfile と同じ階層にある hooks ディレクトリに build や post_push などの shell ファイルを置くことで処理をカスタマイズできるので、post_push でタグ付けするようにしています。

#!/bin/bash
set -eu

if [ "${DOCKER_TAG}" = "latest" ]; then
  LIZARD_VERSION=$(docker run --rm ${IMAGE_NAME} --version)
  docker tag ${IMAGE_NAME} ${DOCKER_REPO}:${LIZARD_VERSION}
  docker push ${DOCKER_REPO}:${LIZARD_VERSION}
fi

こちらは「ブログズミ: [DockerHub] AutomatedBuild でバージョンタグを自動でつける」で紹介した方法と同じです。

これでパイプラインは完成です。

今回は以上です。では。

wandbox-builder のテスト環境構築

 最近 Wandbox のコンパイラー環境を作成する wandbox-builder に PR 投げまくっており、その際のテスト環境構築で詰まったところを備忘録としてメモしておく。
なお、本流にマージしても問題ないだろうと思う部分は PR を出しています。

kennel.json の修正

https://github.com/srz-zumix/wandbox-builder/pull/1/files#diff-39e78c9920d894556bc58bc9693d6357a2737275ce6c2ac89198d8caed4e3c64
Wandbox の更新に追従が必要です。
.session.key と db ファイルはテスト環境のものを参照するようにし、それらのファイルは追加・作成するように変更しています。

ip 制限処理への対応

https://github.com/srz-zumix/wandbox-builder/pull/1/files#diff-8339ab6ea29831802ca594668bddeb7e22d576a0cee4bb6a5492cb104492c98f
Wandbox で ip 制限がかかるようになったのですが、テスト環境からテストスクリプトを実行した際に「 [warning] [kennel.cpp:409] X-Real-IP is empty」となり、失敗していました。
ヘッダに「X-Real-IP」を追加して回避しました。
（これが正攻法なのかはわからないです）

setuid の失敗への対応

こちらは筆者の実行環境が macOS なのが関係してるかもしれません。
マウントしたパスへの setuid が以下のように失敗するようなので、cattleshed の設定で uids オプションを削除するようにしました。
「cmake-head: {u'status': u'1', u'compiler_error': u'setuid: Operation not permitted\n', u'compiler_message': u'setuid: Operation not permitted\n'}」

https://github.com/srz-zumix/wandbox-builder/pull/2/files

以上、Wandbox に言語やコンパイラバージョンを追加したい場合の参考になれば幸いです。

[Wercker] DockerHub pull rate limit に対応する

 ブログズミ: [CodeShip][Drone.io] DockerHub pull rate limit に対応する
こちらに引き続き、Wercker での対応方法をまとめます。

その前に Wercker は Oracle に買収されてから手付かずな状態なのかと思ってましたが、
Slack コミュニティは生きていて今回の対応方法も Slack コミュニティで知りました。
まだ Wercker 使ってる人は入っておくといいと思います。

DockerHub pull rate limit に対応

では本題の対応方法です。

Box に対しては以下のように box 指定で user/pass を設定します。

box:
  id: python
  username: srzzumix
  password: ${WERCKER_DOCKERHUB_PASSWORD}
  

ステップ内で docker 使う場合は普通にログインすれば OK です。

    - script:
        name: Login DockerHub
        code: |
          echo ${WERCKER_DOCKERHUB_PASSWORD} | docker login -u srzzumix --password-stdin

今回は以上です。
では。