GitHubプロフィールをカッコよくするGitHubActionsをつくってみた（つもり）

season 版：

season 版は、春夏秋冬をそれぞれ桜花→夏草→紅葉→積雪をイメージした色にしています。

GitHubActionsに毎日１回起動するように登録しておけば、上記のような画像(SVG)が自動で生成されます。profile にこの自動生成される画像を最初に一回貼り付けておけばOK。ブログなどにも貼り付けられます。

また、勢い余ってマーケットプレイスにも公開してしまいました。

作ってみてわかったのは、自分にカッコよくするセンスがないということでした。

【追記】

ver3.0.0で以下のようなバージョンも追加しました

（これ👆は、お時間があれば10秒ぐらい眺めていてください）

こちらも参考に

ver0.5.0 や ver0.6.0 でも別バージョンを追加しています。

【追記ここまで】

ちなみに

これは、GW に書いた駄文３本のうちの１本です。気が向いたらほかの物も読んでみてください。

きっかけ

偶然見かけた以下の Qiita 記事がきっかけになりました。

• GitHub のプロフィール用のリポジトリの話
• GitHubActions で GitHub のプロフィール用リポジトリに自動で画像を生成するツール
• GitHub のコントリビュートカレンダー（いわゆる芝生）の立体化するブラウザ拡張

なんだか、自分でも作ってみたい！　とおもったのです。

使い方

使い方を簡単に記載しておきます。

手順 1. プロフィール用のリポジトリを作る

ユーザー名と同じ名前で GitHub にリポジトリを作成してください。
（既に作成済みなら、そこを使ってください）

例えば、ユーザー名が octocatの場合は、octocat/octocat という名前のリポジトリを作成します。

私の場合は yoshi389111 なので、new repository を選んで yoshi38911 という名前でリポジトリを作れば yoshi389111/yoshi389111 になります。

新しく作成したリポジトリで、以降の手順を実行します。

手順 2. ワークフローファイルを作る

リポジトリで Add file -> Create new file を選んで、以下のようなファイル名でワークフローファイルを作成します。

• ファイル名： .github/workflows/profile-3d.yml

スケジュールは1日1回開始するように設定されています。
起動時間を都合の良い時間に修正してください。

cron の指定は UTC なので、そこだけ注意してください。
以下のサンプルは日本時間の深夜（早朝）の３時に動くようになっています。

season版のサンプル

手順 4. README.md を追加

生成された画像のパスを readme ファイルに追加します。
画像は４つあるので、内容を見てお好みの物を選んでください。

例：

![](./profile-3d-contrib/profile-green-animate.svg)

補足１：コミットするメールアドレスについて

workflowファイルの git config には GitHubActions のサンプルに書いてあったメールアドレスと名前を書いています。
お分かりだとは思いますが、この状態では自動コミットで芝は生えません。

ズルしたくない、という人は上記のままで問題ないと思います。
どうしても他人のメールアドレスでは嫌だという人は、GitHub に登録されていないご自分のメールアドレス（例えば gmail のエイリアスなど）を登録してください）

逆に自動で芝生を生やしたいという人は、GitHub に登録しているメールアドレスにすることで自動で１日１回のコミットをする、自動芝植えマシンになると思います。

補足２：プライベートリポジトリも集計対象としたい場合

上記の secrets.GITHUB_TOKEN は自動で作られる特別なトークンです（詳細は以下を参照）。

secrets.GITHUB_TOKEN を使う場合、プライベートリポジトリの情報は権限的に取得できないため、集計対象はパブリックリポジトリだけになります。

詳しく言えば、コントリビュートカレンダー（芝生）と、それ以外ではプライベートリポジトリを含めるかどうかの設定方法が異なります。

コントリビュートカレンダーについては、プロファイル画面にある設定 Contribution settings から Private contributions を選ぶと、SVG 画像にもプライベートリポジトリの情報が反映されます。

コントリビュート数や、星の数、フォーク数などは、secrets.GITHUB_TOKEN を使っている場合にはプライベートリポジトリ分は集計されません。

プライベートリポジトリも集計対象とする場合は、「personal access token」を新しく作って（あるいは既存の物を）リポジトリに登録し、ワークフローファイルで指定されている GITHUB_TOKEN に設定します。

多分、以下のような手順になると思います。

• ユーザーの settings -> Developer settings -> Personal access tokens でトークン作成(repo/userのread権限)
• 自分の名前のリポジトリの settings -> Secrets に PERSONAL_ACCESS_TOKEN を登録
• secrets.PERSONAL_ACCESS_TOKEN を環境変数に登録する

        env:
-         GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+         GITHUB_TOKEN: ${{ secrets.PERSONAL_ACCESS_TOKEN }}
          USERNAME: ${{ github.repository_owner }}

ちなみに「ユーザーの settings」と「リポジトリの settings」は別物なのでご注意ください。

作成した時の話

以下は、作成したときに考えたことや、詰まったことなどをメモしておきます。

GitHub GraphQL

まず、芝生の立体化はやってみたい。

芝生情報を取得する方法は、大きく分けて２つありそう。

１つは、GitHub の GraphQL で問い合わせて情報を取得する方法。

もう１つは、GitHub のプロフィールページに含まれる SVG を解析する方法。

今回はいろいろ考えて、GraphQL にしました。
というか、その他の情報（言語情報とか、全リポジトリの星の合計数とか）も取得して載せたかったので、ほぼ一択だったとおもう。

とりあえず、欲しい情報をまとめてみました。

• コントリビュートカレンダー（芝生）の情報
• コントリビュートの種類と数（commit, issue, PullRequest, Review, Repository）
• コントリビュートの言語種類
  • 厳密にいえば、コントリビュートの言語ではなく、コントリビュートしたリポジトリの主要言語をつかう
• 全リポジトリの星の数と、フォークされた数

GraphQL を使うのは始めてだったのですが、GraphQL は以下のサイトで実際に試せるので、まずはクエリを作って試してみました（最初に使うときに認可が求められるので、確認してOKする）

クエリーはこんな感じかな（ソースは直しても記事の方は直さないので少し古い版かもしれません。参考にするときには注意してください）

query ($login: String!) {
  user(login: $login) {
    contributionsCollection {
      contributionCalendar {
        totalContributions
        weeks {
          contributionDays {
            contributionCount
            contributionLevel
            date
          }
        }
      }
      commitContributionsByRepository(maxRepositories: 100) {
        repository {
          primaryLanguage {
            name
            color
          }
        }
        contributions {
          totalCount
        }
      }
      totalCommitContributions
      totalIssueContributions
      totalPullRequestContributions
      totalPullRequestReviewContributions
      totalRepositoryContributions
    }
    repositories(first: 100) {
      nodes {
        forkCount
        stargazerCount
      }
    }
  }
}

現状は、見ての通り集計対象のリポジトリ上限は100個にしています。
（……でも100個以上のリポジトリ持っている人もいるよな、どうしよう）

SVG の組み立て

情報が取得できたら、次は SVG の組み立てです。

SVG の中身は、単なる XML なので、全部自力で造ることも可能だけど、せっかくなので d3.js を活用してみました。

以前、古い版の d3.js を少しだけ使ったことがあるので、作ること自体はそこまで困りませんでした。
（TypeScript で作っていたので、型で少し悩んだところがあるぐらい）

また、SVG にはアニメーションができる機能があるというのを以前見かけたので、今回はそれも取り込もうと考えました。
SVG のアニメーションというと、JavaScript から SVG を加工してアニメーションをするか、CSSでアニメーションするかのイメージですが、SVG のタグでもある程度のアニメーションはつくれるようでした。
具体的には <animate> タグを登録して、時間に応じて値を変化させることができるようです。

今回は、立体化した芝生（緑のビルみたいな感じ）が表示した直後は短くなっていて、そこからググーっと伸びるようなアニメーションを設定してみました。

この時点では GraphQL は実際にはたたかず、上記エクスプローラで返ってきたデータをダミーデータとしてファイルに保存して、それをもとにSVGを作成するプログラムを作りました。

SVG の組み立てる作業自体は特に問題なかったのですが、一番の問題は（冒頭でも言った通り）色や配置、見せ方のセンスが全くないということでした。絶望。

データーの見せ方について

前述の通り、今回は以下の情報をまとめて表示しようと思っています。

• コントリビュートカレンダー（芝生）の情報
• コントリビュートの種類と数（commit, issue, PullRequest, Review, Repository）
• コントリビュートの言語種類
  • 厳密にいえば、コントリビュートの言語ではなく、コントリビュートしたリポジトリの主要言語をつかう
• 全リポジトリの星の数と、フォークされた数

芝生情報は立体化して表示するのが決まっていますが、それ以外をどう表現するかを考えました。

コントリビュートの種類については、レーダーチャートっぽく見せようと思いました。
ただ、通常の GitHub プロフィールも設定を変えるとレーダーチャートっぽいものが表示されますよね。
でも、あのチャートだと件数の多いものと少ないものの差が大きくて、よくわからない気がしています。