GitHubのprivate repositoryを含んだ場合のGo Modules管理 | おそらくはそれさえも平凡な日々
tl;dr CI/CD環境から複数のGitHubのprivate repositoryにアクセスさせたい場合にはmachine account(machine user)を使うと良い SSH KeyでもAPI tokenでもどちらでも良いけどSSH方式がGo公式repoでも紹介されている CircleCIだとSSH Keyの設定(User Key)が簡単でその他の設定がほとんど不要 本題 Goに限った話ではありませんが、プロジェクトで使っているprivate repositoryからまた別のprivate repositoryを参照している場合、CI/CDなどの外部環境からどのようにそれらにアクセスさせるか困ることがあります。 例えば、git submoduleを使っている場合や、Goの場合ですとGo Modulesで指定しているパッケージがprivate repositoryである場合な
CircleCIでgit-pr-releaseする | おそらくはそれさえも平凡な日々
git-pr-releaseそのものの説明に関してはninjinkunの以下のエントリを参照ください。 git-pr-releaseのすすめ さて、現職に入社したら、git-pr-releaseが使われていたのですが、リリース担当者が手元で実行するフローになっていました。しかし、git-pr-releaseの本場であり発祥の地でもある、はてな社では、git-pr-releaseはCIに作らせるものであったので、それに倣って、こちらも現職で利用しているCircleCIに作らせるようにしてみた。 手順 .git-pr-releaseをrepositoryに配置する GIT_PR_RELEASE_TOKEN をCircleCIに登録する .circleci/config.yml にjobを設定する おまけ machine accountを作るといいよ Triage(トリアージ)権限が便利 1.
できないことを、淡々と「できるよね？」と言われるのが、えらいシンドかったという話。
これは以前も書いたような気がするのだけど。 僕はかつて、「よかれ」と思って後輩にミスを淡々と指摘し続けて、鬱一歩手前にしてしまった事がある。 治すべきミスをキチンと指摘してあげたほうが、その後の改善ポイントがわかりやすいと思っての事だったのだけど、結果としてはあまり良いものとはならなかった。 なぜ後輩が落ち込んでしまったのか、正直なところ以前は正直よくわからなかった。 「仕事というのは怒られるうちが華」と洗脳にも近い形で教育されてきた身からすると、説教されずにファクトだけをベースに指導してもらえるだなんて、夢のような話じゃないかと思っていたぐらいである。 ところが最近、ちょっとした病をやり、自分自身がそれまで物凄く簡単にできていた事が全然できなくなった事により、目の前で出来ないことを淡々と「できるよね？」と言われる事がエラいシンドイということを身をもって知ることとなった。 「できません」と
3年間毎週社内勉強会を継続してきた秘訣（後編）｜TechRacho by BPS株式会社
前回の記事はこちら：3年間毎週社内勉強会を継続してきた秘訣（前編） morimorihogeです。最近アバターをFSMから社員用イラストに変えました。思ったより世の中の人はスパモン教のことを知らないということで、パスタファリアンには肩身が狭い世の中です。 前回では社内勉強会の企画～実践について書いてきましたのが、後編では開催の継続化と運営側のモチベーション管理について書いていこうと思います。 社内勉強会を継続することの難しさ 社内勉強会は参加者が社内メンバーメインとなることもあり、比較的開催しやすいと思っている方もいるかと思います。 しかし、当日の来場者対応などが手を抜けることは確かですが、継続して続けていくにはやはり難しい点が多々あります。 ※1回だけ開催することが目的であれば前編を参照してください 実際に週1回、月1回など継続した社内勉強会開催を目指してみると、多くは以下のような要因で
社内技術書輪読会とSite Reliability Engineering | フューチャー技術ブログ
TIG/DXユニット 1所属のLEEです。 2019年より社内で輪読会を企画運営し、このたび初回の課題図書になってたSite Reliability Engineering を全10回で無事読破できました。 これを記念に実施概況をまとめさせていただきます。 Who am I名前から分かる通り韓国出身で、入社してちょうど1年くらいになりました。前職がWeb系の会社のエンジニアだったのでITコンサルティングを生業とするフューチャーに入社したのは、ある意味エンジニア界隈のトレンドに逆走した感じかもしれませんが、外には出せない情報ばかりの貴重な経験をさせてもらえているので良い決断だったと思っています。 背景入社して今までの会社と違う環境で戸惑いながらも、自分が慣れているWeb系のテイストを取り入れようとしました。 その一つが社内勉強会の企画でしたが、すでにいくつか定期開催済みということもあり、もう
たぶん参考にならない、僕のリモートワーク知見（開始1ヶ月時点） - えいのうにっき
以下のエントリの通り、7月からリモートワークを開始しています。 blog.a-know.me 社会人になってからはや15年、ずっとオフラインな働き方をしてきたしどちらかというと自分自身でもオフライン派だと思っている自分が、「リモートワークを始めた際に気をつけたこと」「開始から1ヶ月弱が経過した時点で気をつけていること」をメモしておこうと思い立ち、こうしてキーボードを叩いています。 今月末でリモートワーク開始1ヶ月だし、その時点での僕なりのリモートワーク知見をアウトプットしとこうかなー。 3ヶ月後、半年後、くらいにも書き残しておくと良さそうな感じがしている。— a-know (@a_know) July 17, 2019 ひととおり書いてみたものの、たぶん僕がちょっと変だからだと思うんですがあまり参考にならない内容もあると思うので、あまり期待はしないでください......。 仕事をするための
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Hatena ID
GitHub - pinterest/ktlint: An anti-bikeshedding Kotlin linter with built-in formatter