恐らく公式ドキュメントに説明がない気がするので書いておきます。 と言っても、以下のissueに全部書いてありますが。
https://github.com/drone/drone/issues/2042
droneの web ui からリポジトリごとに設定できます。 そのリポジトリが誰に見えるかの設定です。
drone 0.8.5 で検証しています。
drone の build の タイムアウトの設定はリポジトリの settings から変更できそうですが、 実は drone の admin しか変更できません。
ブラウザのデベロッパーツールを使うと、この Timeout の設定を変更した際に
PATCH /api/repos/:owner/:name
にリクエストが飛んでいるので、そこからコードを追いかけると分かります。
drone の build における GitHub (GitHub前提で書きますが、GitHub以外でも同じだと思います) の認証の話(どうやって認証しているか)について書いておこうと思います。 drone の build は clone step で対象のリポジトリを GitHub から clone してきています。 この際に何かしらの方法で認証しているはずです。
結論を言うと、
あるリポジトリAのbuildでは、 リポジトリAの drone連携を有効化したユーザー Bの access token を .netrc に書き込んで認証しています。 よってユーザーBにcloneする権限があるリポジトリはcloneできるし、 ユーザーBにcloneする権限がないリポジトリはcloneできません。 つまり、 誰が連携を有効化するかが重要 になります(これについては後述します)。 なお、drone連携の有効化はそのリポジトリのowner以上でないと出来ません。
drone上でリポジトリの連携を有効化すると、 リポジトリのHookが作成されます。 リポジトリの settings > Hooks から確認できます。 この Hook の Payload URL を見ると access_token クエリがあると思います。 JWTのようですね。これはリポジトリの連携を有効化したユーザーのtokenです。
このtokenが GitHub から drone への webhook のパラメータとして送られてくるので、 drone 側で認証し、認証したユーザーのGitHub のaccess token を取得し、 build 時にコンテナの /root/.netrc に書き込むようです。
.netrcに書き込まれているのは試しに個人の private repository で .netrc をcatしてみればわかります。 他人も見えるrepositoryでcatすると悪用されかねないので気をつけましょう。
pipeline:
netrc:
image: alpine:3.6
commands:
- cat ~/.netrc
+ cat ~/.netrc
machine gihub.com
login **************
password x-oauth-basic
.netrc のおかげで難しいこと考えずに clone 出来ているわけですが、この .netrc は当然 clone ステップ以外でも使えます。 例えば private repository の ansible role の install です。
roles.yml
- src: https://github.com/<owner>/<repo>
name: foo.bar
scm: git
.drone.yml
commands:
- ansible-galaxy install -r roles.yml
結論を言うと、ベストな方法は分かりません。
連携を有効化した人が退職してしまったり、organizationから抜けてしまった場合、急にビルドが失敗するリスクがあります。 理想を言えば特定の個人のアカウントで連携するのではなく、連携用のアカウントを用意するのが良いのかもしれませんが、 それはそれで運用が難しいかもしれません。
drone API ないし CLI で有効化は出来るので、CIで連携を自動化することは可能だと思います。
自分のところではまだそこまでやってなく、個人で有効化してしまっているのですが、 自動化したらまた記事にでもしたいと思います。
drone は同じ pipeline の step 間で同じ workspace を docker の volume としてマウントすることで workspace を共有します。
http://docs.drone.io/workspace/
circle ci はデフォルトで job 間で workspace を共有しません。 persist_to_workspace を指定することで共有する事ができます。
https://circleci.com/docs/2.0/workflows/#using-workspaces-to-share-data-among-jobs
circle ci の場合は volume を共有するのではなく、指定したディレクトリを archive し、次の job で展開することでファイルを共有するようです。
この違いには一長一短があります。
circle ci の場合は archive, unarchive する分、volume 共有に比べて時間がかかります。
そのため、下手に job を分けるより一つの job で処理したほうが処理時間が短くなる場合がありますが、 build や test といった処理は出来れば別の job として実行したいでしょうし、それでは workflow が使えません。
ただし、共有するパスは自由に選べるので必要最小限に抑えることで時間を短縮できます。
また、circle ci の場合は archive するパス及び展開先のパスを自由に選べるので自由度が高いです。 drone の場合、 workspace 以外のファイルを共有できません。
また、drone の場合 volume を共有するので同じ pipeline の step は同じノードで実行されるという制約がありますが、 circle ci の場合、別のノードでの実行が可能です。 drone の group を使って並列に実行する場合、複数のノードに分散できませんが、 circle ci の場合分散できるのでよりスケールしやすいと言えるでしょう。
一長一短があると言ったとおり、一概にどっちが良いとは言えませんが、個人的には drone のやり方のほうが直感的だし、 何より速いので好きです。同じ pipeline の処理を複数のノードに分散させたいことって個人的にはあまりありません。
drone exec を並列実行すると docker network name が衝突することがあります。
$ drone exec --local & drone exec --local
[1] 42934
2018/06/06 01:58:12 Error response from daemon: network drone_default is ambiguous (4 matches found on name)
2018/06/06 01:58:12 Error response from daemon: Conflict. The container name "/drone_step_0" is already in use by container "464a29b0726d6ff1a352d81df9c837330501085be550bb16abac3d338dfad887". You have to remove (or rename) that container to be able to reuse that name.
[1] + exit 1 drone exec --local
drone は pipeline 実行時に network を作成し、pipeline が終了すると network を削除します。
削除するので、並列で実行しない限り基本的に衝突したりすることはありません。
なお、 docker の仕様では同じ名前の network を作成できるようです。
drone exec は {prefix}_default というネットワークを作成します。
{prefix} はデフォルトで drone ですが、コマンドライン引数で指定できます。
このprefixを変えれば衝突は回避できます。 bash, zshなら次のように乱数を指定すれば良いと思います。
$ drone exec --local --prefix drone_${RANDOM}
なお、 drone exec --help の中に --prefix オプションはありませんが、これは明示的にhelpから消しているからです。
なぜ消しているかは分かりません。
なお、 drone の build では prefix に プロセスIDと乱数を使うことで衝突を避けているようです。
https://github.com/drone/drone/blob/29785b86f6534ded974120de0fcf7c21397a9d0d/server/hook.go#L552