- 投稿日:
GitHubの無料アカウントを2つ持つことは規約で禁じられているため、例え個人用と業務用であっても2つは持てないという話がまことしやかにありますが、実は分けられるという話です。
規約違反の根拠
GitHubは利用規約でアカウントの要件として次のことを掲げており、そのまま読むと規約違反になります。
1 人の個人または 1 つの法人が複数の無料「アカウント」を保持することはできません (コンピュータアカウントも制御することを選択した場合、それは問題ありませんが、それはコンピュータの実行にのみ使用できます)
規約違反であるという説
次の記事では規約違反であるとされており、GitHub内部の人物からもその確認を取ったとされています。
規約違反ではないという説
次の記事では「会社側で有償のオーガニゼーションを契約し、仕事用アカウントを所属させていれば」規約違反でないとされています。
問い合わせてみた結果
個人的に納得できなかったのでギットハブ・ジャパン合同会社に問い合わせてみました。
結論としては公私混同を避けるため個人用と業務用で無料アカウントを2つ持つことは許容されているとのことでした。この規約の存在理由としては主にOSSでの荒らしの防止策のためということでしたので、会社側で有償のオーガニゼーションを契約するとかも特に不要という内容です。
プライベートのGitHubアカウントに業務の通知が貯まるのは嫌なので助かりました。理由としては通知が邪魔くさいことと、やっぱりプライベートと業務は分けときたいよねという思いが大きいです。
例えば兼用しているとSSOログインしていない状態でもGitHubサイト右上の通知アイコンは通知ありの状態になりますし、プライベートではSSOログイン出来ないため通知は消化できないですし、仮に出来たとしても業務時間外に消化したくないです。
またアカウントを業務とプライベートでごっちゃにしてると権利周りが面倒くさくなるため、それを避ける意味合いもあります。これは場合によっては功績として使えたりなどで、利点になることもありますが、個人的にそこはいいかなという感じです。
- 投稿日:
GitHub Actionsで前のジョブの結果を後続で利用したい時に使えるやつ
サンプルコード
- 適当な文字列を変数にセットして、各ジョブで出力する例
name: outputs sharing example
on:
pull_request:
jobs:
first:
runs-on: ubuntu-latest
outputs:
# <out-job-name>: ${{ steps.<step-id>.outputs.<in-job-name> }}
baz: ${{ steps.foo.outputs.bar }}
steps:
- uses: actions/checkout@v3
with:
fetch-depth: 0
- id: foo
# この場合、FOO-BARという値がセットされる
run: echo "::set-output name=bar::$(echo FOO-BAR)"
- id: test
# steps.<step-id>.outputs.<in-job-name>
run: echo "${{ steps.foo.outputs.bar }}"
second:
needs: [first]
runs-on: ubuntu-latest
steps:
- id: test
# needs.<job-id>.outputs.<out-job-name>
run: echo "${{ needs.first.outputs.baz }}"
参考
- 投稿日:
Issueの中にあるTasksの進捗状況集計したい。したくない?したいですよね!
実はGitHubのREST APIを叩いてもTasks情報を素直に取れません
仕方がないので雑に取得するためのシェルスクリプトを書きました
自作するまでの経緯
GH CLI では出来ない
GitHub CLI使ったら簡単に出来るやろ、そう思っていた時代が私にもありました
なんとできません
検索クエリ投げないとProjectで絞れないようなかったり、痒いところに手が届かない子ですし、まぁ許しましょう
REST APIでもできない
ちょっと待ってほしい、画面上表示されてるのにAPIとしては提供されてないの?
そんなのある?
そんなデータを提供している機能はない
2016年には問題提起されていたようですが絶賛放置中
仕方ないので自作した
API叩いてIssue本文からTasksの情報を雑に抜いて集計するだけのやつです
超雑なのでインデントとかコードフェンスの中とか何も考慮してません
- 投稿日:
pull_request
イベントの公式リファレンスが手薄くイベントの意味を明示してないので動きを実際に確認したものをメモ程度に。基本は意味のままだと思いますが…
opened: PRが開いたとき
reopened: PRが開き直されたとき
synchronize: PRに対してPushが走ったとき
- 公式リファレンス
特定ブランチから特定ブランチへのPRを阻止する
- サンプルで作っただけなので中身は適当
pull_request
はbranches
を先頭に書かないと、指定ブランチ以外でも走るので注意
name: testing on opend PR to main
on:
pull_request:
branches:
- main
types:
- opened
- reopened
- synchronize
jobs:
# 事前ブランチチェック
before-check:
runs-on: ubuntu-latest
steps:
- name: fail case
if: startsWith(github.head_ref, 'test/') && github.base_ref == 'main'
# test/* ブランチから main ブランチ宛である場合
# exit 1で終了することで Workflow を failure 扱いにする
# https://docs.github.com/ja/actions/creating-actions/setting-exit-codes-for-actions
run: exit 1
# 前の if に入らなければ、そのまま次のジョブにつながる
after-exec:
# 指定されたジョブの成功を要求、失敗している場合、このジョブを実行しない
# 必然的に線形実行になる(並列では走らない)
needs: [before-check]
runs-on: ubuntu-latest
steps:
- name: TEST!
run: echo "RUN after-exec"
- 投稿日:
取り敢えず各ジョブの中で使うやつ
今まで使っていた::set-output
は2023-05-31に廃止される予定なので置き換える必要があります。
GitHub Actions: Deprecating save-state and set-output commands
サンプルコード
- 設定方法:
echo "<KEY>=<VALUE>" >> "$GITHUB_OUTPUT"
- 参照方法:
steps.<ID>.outputs.{KEY}
name: variable example
on:
workflow_dispatch:
jobs:
ubuntu-testing:
runs-on: ubuntu-latest
steps:
- id: example
run: echo "value=hoge" >> "$GITHUB_OUTPUT"
- name: disp
run: echo ${{ steps.example.outputs.value }}