RenovateでGitHub Actionsで使っているHugoを更新する

GitHub ActionsとHugoを使用して静的サイト生成を行う場合、peaceiris/actions-hugo を使用するか、自分で適当にHugoをインストールするかのいずれかが一般的だと思います。このブログでは、セットアップ当初はpeaceiris/actions-hugoを使っていたのですが、最近debパッケージを自分でインストールする方式に切り替えました。 gohugoio/hugoのreleases から直接debパッケージを持ってきているので、peaceiris/actions-hugoとは違いlatest指定をする事ができず、Hugoの更新を手動で行う必要があり、ちょっと面倒だな〜と感じていました(しかもHugoは結構開発が活発で、更新もはやいんですよね)。 仕事のリポジトリでは最近renovateがどんどん導入されているので、これを機にrenovateを導入することにしました。 HugoのバージョンはGitHub ActionsのWorkflowファイル内にenvで指定されていて 、もちろん標準状態のrenovateはこれを検知・更新してくれません。これに対応するには、regexManagers を使用します。 regexManagersは正規表現でバージョン番号を引っかけて更新してくれるmanager で、fileMatchとmatchStringsという二つの正規表現を書くことで使う事ができます。 fileMatchはその名の通り、どのファイルを監視するかを指定する正規表現で、今回はGitHub Actionsの設定ファイルを監視して欲しいので、デフォルトのgithub-actions managerが監視する正規表現をそのままコピーしてきて使用しました。 1 2 3 4 "fileMatch": [ "^(workflow-templates|\.github\/workflows)\/[^/]+\.ya?ml$", "(^|\/)action\.ya?ml$" ] matchStringsはバージョンを引っかけるための正規表現で、datasource、depName、currentValueの三つの値をキャプチャするか、datasourceTemplate、depNameTemplate、currentValueTemplateで値を指定する必要があります。datasource(datasourceTemplate)とdepName(depNameTemplate)はバージョンを比較するためのデータソースと依存の名称で、今回はGitHub上にあるgohugoio/hugoリポジトリのリリースと比較をしたいため、datasourceTemplateにgithub-releasesを、depNameTemplateにgohugoio/hugoを指定しました。currentValue(currentValueTemplate)は現在のバージョン番号を表す値で、これはGitHub Actionsの設定ファイルに書かれている値なので、matchStringsで引っかけてキャプチャします。 1 2 3 4 5 "matchStrings": [ "HUGO_VERSION: (?<currentValue>.*)" ], "datasourceTemplate": "github-releases", "depNameTemplate": "gohugoio/hugo" 設定ファイル全体としては次の様になります: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 { "$schema": "https://docs.renovatebot.com/renovate-schema.json", "extends": [ "config:base" ], "regexManagers": [ { "fileMatch": [ "^(workflow-templates|\.github\/workflows)\/[^/]+\.ya?ml$", "(^|\/)action\.ya?ml$" ], "matchStrings": [ "HUGO_VERSION: (?<currentValue>.*)" ], "datasourceTemplate": "github-releases", "depNameTemplate": "gohugoio/hugo" } ] } これで無事renovateがHugoのバージョンをチェックしてくれる 様になりました。めでたしめでたし。 ...

2022-09-27 · nasa9084

GitHub PagesをActionsからデプロイする形式に変更した

2022年9月1日現在、このブログはmarkdownファイルからHugoを使って静的サイトを生成し、GitHub Pagesで公開しています。元々GitHub Pagesにページをデプロイするには、生成済みページを入れた専用のブランチ(一般にgh-pages)を用意するか、生成済みページを入れたディレクトリを用意するか、という二択で、いずれにせよページを生成してから生成されたページをGitHubにpushする必要がありました。前者の場合gh-pagesブランチはmainないしmasterブランチとは一切関係の無いコミット履歴となり、ぱっと見よく分からないですし、後者の場合gitのcommit logにサイト生成のコミットが入ってしまいきれいではありませんし、CIでbuild/pushをしている場合ローカルに毎回pullする必要も発生します。当サイトでもgh-pagesブランチに生成済みページをpushする運用となっていました。 ところが最近、GitHub Actionsから直接GitHub Pagesにページをデプロイできる様になった というではないですか。これは試してみるしかない、ということで設定を変更してみました。 まず、リポジトリのSettings > Pagesから、SourceをGitHub Actionsに変更します。 次に、GitHub Actionsのworkflow設定をactions/starter-workflows を参考に書き換えます。重要なのは2点で、actions/upload-pages-artifactを使って生成済みページをartifactとしてアップロードする点と、actions/deploy-pagesを使ってGitHub Pagesにデプロイをすることです。 1 2 3 4 5 steps: - name: Upload artifact uses: actions/upload-pages-artifact@v1 with: path: ./public 1 2 3 4 5 6 7 8 9 10 11 12 13 # Grant GITHUB_TOKEN the permissions required to make a Pages deployment permissions: pages: write # to deploy to Pages id-token: write # to verify the deployment originates from an appropriate source environment: name: github-pages url: ${{ steps.deployment.outputs.page_url }} steps: - name: Deploy to GitHub Pages id: deployment uses: actions/deploy-pages@v1 多分artifactのアップロードとページのデプロイは同じJob内で実施しても問題無く動くとは思いますが、actions/deploy-pagesのREADME によると専用のJobに分けることが推奨されているようです。 ...

2022-09-01 · nasa9084

GitHubがgit://を無効にした件

TL;DR GitHubからgitプロトコル(git://github.comで始まるURL)でgit cloneする設定になっている人が居たらSSHプロトコル(git@github.comで始まるURL)を使うように設定変更しましょう wez/weztermという端末エミュレータを知って、使ってみようかと思い、ドキュメントに従ってbrew tapしたときのことでした。次の様なエラーが発生して、tapできません。 $ brew tap wez/wezterm ==> Tapping wez/wezterm Cloning into '/opt/homebrew/Library/Taps/wez/homebrew-wezterm'... fatal: remote error: The unauthenticated git protocol on port 9418 is no longer supported. Please see https://github.blog/2021-09-01-improving-git-protocol-security-github/ for more information. Error: Failure while executing; `git clone https://github.com/wez/homebrew-wezterm /opt/homebrew/Library/Taps/wez/homebrew-wezterm --origin=origin --template=` exited with 128. 指定された記事 を見てみると、git://で始まるURLでのアクセス==gitプロトコルでのアクセスを無効化したようです。 自分の.gitconfigを見てみると 、確かに https://github.com の代わりに git://github.com を使うという設定がされています。 [url "git@github.com:"] pushInsteadOf = git://github.com/ pushInsteadOf = https://github.com/ [url "git://github.com/"] insteadOf = https://github.com/ GitHubによるとこれまでもgitプロトコルでのアクセスは読み取り専用だったようですが、ご丁寧にpushInsteadOfで git@github.com を使用するという設定まで書かれているので、これまで問題無く使えてしまっていたようです。自分でもなぜこういう設定にしたのか記憶にないのですが、これは単にSSHプロトコルを使用すれば良いだけ、ということのようでしたので修正しました 。 [url "git@github.com:"] insteadOf = https://github.com/ GitHubの想定としてもどうせread-onlyだから使っている人なんてほとんどいないだろう、ということで引っかかる人も居ないでしょうが、メモとして残しておきます。 ...

2022-03-20 · nasa9084

社用Gitサーバでは社用のメールをつかう.gitconfig 〜社内ドメインを外に漏らさない編〜

GitHubのコミットログ、コミットした人のアイコンが出ていてとてもわかりやすいですよね。 コミットとアカウントの紐付けにはどうやら、コミットに紐付けられたメールアドレスが使用されているようです。そうなると、コミットに紐付ける(git config user.email=...とかやるアレです)メールアドレスはアカウントに登録してあるメールアドレスにしたいものです。 しかし、会社ではGitHub Enterprise(GHE)、私用ではgithub.com を使用している、と言った場合はどうでしょうか。コミットに紐付けたいメールアドレスがリポジトリによって変わる、ということになってしまいます。 調べてみると、そういった場合、次の様に.gitconfigにIncludeIfのブロックを設定することでうまく回避ができそうということがわかり、しばらく設定していました 1 2 [IncludeIf "gitdir:~/src/GHE_DOMAIN"] path = "~/.gitconfig.ghe" ~.gitconfig.gheには次の様に書かれています。 1 2 [user] email = 社用メールアドレス 私はGo言語をよく書くのと、ghq を使っている都合上、gitのリポジトリを配置するパスが$(GOPATH)/src/GIT_DOMAIN/USERNAME/REPOSITORYという形式になっているため、リモートリポジトリのドメインを指定することでうまいこと社用GHEの時だけ設定を上書きすることができていたのでした。 そしてこれは、どのPCでも使用できるように、dotfilesリポジトリ としてgithub.com にpushしていました。 その結果、会社の人から、「社内のサービスのURL(この場合はGHEのURL)はセキュリティ的な理由から外に出さないようにしてほしい」と連絡を受けました。すぐさま該当のブロックは消したのですが、そうするとメールの設定が自動でされなくなってしまい不便です。リポジトリのパスを変更するというのも、せっかくの統一的な操作に違いが出てしまい、不便です。 そこで思いついたのが、こういったセンシティブな情報を別のプライベートリポジトリに分け、Makefile でインストールを自動化するという方法です。 パブリックなdotfilesリポジトリ にある.gitconfig には次の様に書いてあります。 [include] path = ~/.gitconfig.secret .gitconfig.secretはその名の通り、秘匿情報を含んだ.gitconfigで、プライベート化されたdotfiles-secretリポジトリにおいてあります。dotfiles-secretリポジトリはmake installとしたときにgit cloneされ、さらにそのディレクトリ内のMakefileにより配置されます。dotfiles-secret/.gitconfig.secretには先ほどのIncludeIfブロックが書かれており、同リポジトリ内の.gitconfig.secret.ghe(名前を少し変えました)を読み込みます。 これで、全体の使い勝手をほとんど損なうことなくどのマシンでも(dotfilesが配備済みなら)同様に設定することができました。 Makefileは特にdotfilesのリストを持たないよう記述しているため、新しいdotfileが増えても、特にMakefileの変更をする必要も無く安心です。

2019-08-24 · nasa9084

hubコマンドにGitHub Enterprise環境を追加する

hub コマンドをご存じでしょうか。インストールしてalias git=hubと設定するだけで、gitコマンドからGitHubの操作ができるようになる優れものです。特に個人的にはgit createとするだけでGitHub上にリポジトリが作成される、というのが非常に便利だと思っています。 さて、皆さんの会社ではgitサーバはどのように構築されているでしょうか。いろいろな選択肢がありますが、それなりの規模だとGitHub Enterprise(以下GHE)を利用している、という会社も多いと思います。 実際、現職ではGHEを使っています。 そのような場合、趣味/個人の開発ではgithub.com、会社ではGHEと使い分けることとなりますが、GHEでhubが使えないとすると非常に不便です。そう考えて調べてみると、Web上では、hubをGHE環境で使うには環境変数を使うとする設定例が散見されます。 しかし実は、hubは複数環境での使用をサポートしているんです。 設定方法は至って簡単で、$HOME/.config/hubに設定を書き足すだけです。実際に見てみましょう。 すでにhubを使っている場合、cat $HOME/.config/hubで設定を見ることができます。私の場合、次のようになっていました(oauth_tokenは潰してありますが、実際にはトークンが入っています)。 1 2 3 4 github.com: - user: nasa9084 oauth_token: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx protocol: https どんな項目かは明らかですね。ここに会社のGHEの環境に関する情報を追記します。 まず、自社のGHEのアドレス以下/settings/tokensを開きます。Generate new tokenボタンをクリックし、新規でPersonal access tokenを発行します。名称はわかりやすい物を任意で付けてください。hubはリポジトリを操作するコマンドですから、scopeはrepoを与えれば十分でしょう。画面下部のGenerate tokenボタンをクリックすると、トークンが発行されますので、これをコピーしておきます。 手元のエディタ(お好みの物を使用してください)で$HOME/.config/hubを開き、設定を追加します。 1 2 3 4 YOUR_GHE_DOMAIN: - user: YOUR_USERNAME oauth_token: YOUR_TOKEN protocol: https オブジェクトのキーとしてGHEのドメインを、userはGHEでログインに使用するユーザ名を使用します。oauth_tokenに先ほど生成したPersonal access tokenを設定し、保存します。保存できたら、hubでGHEにアクセスができるようになっているはずです。 実際に使うと、次の様にどのホストを使用するか聞かれ、好きな方を選べるようになっています。 1 2 3 4 5 6 7 $ git create Select host: 1. github.com 2. YOUR_GHE_DOMAIN > 1 Updating origin https://github.com/nasa9084/REPOSITORY_NAME

2019-08-22 · nasa9084

git repositoryの初期化ルーチン

おそらくみなさんもgit repositoryを作る時、毎回だいたい同じような手順で初期化をするのではないでしょうか。 メモがてら、自分の初期化ルーチンをまとめておきます tools 使用しているツールは以下の通り: hub : .zshrc でgitコマンドにエイリアスを張ってます gitignore.io : 先日記事を書いたように 、git ignoreコマンドとして使ってます git-license : 自作のサブコマンドです routine 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 # 新しいリポジトリ用のディレクトリを作成 $ mkdir new-repository $ cd new-repository $ git init # GitHub上にnasa9084/new-repositoryリポジトリを作成 # hubコマンドの機能 $ git create # まずは空の状態で初回コミット $ git commit -m 'initial commit' --allow-empty # .gitignoreを作成(今回はgo言語プロジェクト向け) $ git ignore emacs,macos,go > .gitignore $ git add .gitignore $ git commit -m 'add .gitignore for emacs,macos,go' # LICENSEを作成 $ git license -u nasa9084 mit > LICENSE $ git add LICENSE $ git commit -m 'add MIT License' $ git push -u origin master ここまでがルーチンで、ここからMakefileを作ったり開発したりします。 ...

2018-12-07 · nasa9084

Generates LICENSE file: git-license

When we create a new repository on GitHub , we can choose an open source license. We choose an OSS license, then, LICENSE file is put into the new repository. Now, I’m usually using hub command to create a new repository. I’ll do below to create: 1 2 3 4 5 6 7 8 $ mkdir my_new_repository $ cd my_new_repository $ git init # # ... some code writing and commit ... # $ git create # git command is aliased to hub $ git push -u origin master In this flow, I can write description for repository1, set homepage2, make the repository private3, but I CANNOT choose LICENSE. I can choose and create LICENSE file on the GitHub web page, or I can copy from my other repositories because its content is fixed. However, I don’t do that. ...

2018-02-21 · nasa9084