Nx の攻撃から学べること #s1ngularity | blog.jxck.io
Intro Nx リポジトリが攻撃を受け、広範囲にわたるインシデントが発生した。 今回の事例は、GitHub Actions を中心に複数のステップが組み合わさった攻撃であり、過去に何度も発生してきた攻撃と本質的には変わらない。 しかし、途中で AI が何度か登場するため「AI が書いたコードをマージしたから」などといった表面的な反応もあるが、実態はそこまで単純な話でもない。 また、「自分のプロジェクトは Nx を使っていないから関係ない」とも言えない攻撃であるため、特にフロントエンドエンジニアは全員注意と確認が必要となる。 この攻撃が何だったのか、そこから学べることは何なのか、解説する。 Nx Incident 今回のインシデントについては、既に公式の Advisory が出ている。ニュース系の記事も多々あるが、一次情報は以下となる。 Malicious versions of Nx a
プルリクエスト時にラベルから自動でチェックリストを作成・更新するGitHub Actionを作成した
今回はPull Requestを読み取ってこんな感じのチェックリストを自動生成する kasaikou/pr-checklist-action というGitHub Actionを作成したのでその紹介をする記事です。 TL;DR プルリクエストテンプレートにチェックリストを入れがちだけど、知見が溜まっていくに従ってチェック項目が増えていくのはつらいよ そこで、設定されたラベルをもとにチェックリストを自動作成する GitHub Actions を作ったよ actions/labeler と併用することでラベル設定のめんどくささは actions/labeler が解決するから、それに相乗りするだけでいいよ 基本的にはチェックリスト用のコメントが作成されるけれど、少しテンプレートを変更することで今までのプルリクエストテンプレートっぽいチェックリストを作成することもできるよ 背景とかコンセプト 個人
pull_request_target で GitHub Actions の改竄を防ぐ
本記事では GitHub Actions で pull_request event の代わりに pull_request_target を用い、 workflow の改竄を防いでより安全に CI を実行する方法について紹介します。 まずは前置きとして背景や解決したいセキュリティ的な課題について説明した後、 pull_request_target を用いた安全な CI の実行について紹介します。 本記事では OSS 開発とは違い業務で private repository を用いて複数人で開発を行うことを前提にします。 長いので要約 GitHub Actions で Workflow の改竄を防ぎたい GitHub の branch protection rule や codeowner, OIDC だけでは不十分なケースもある pull_request event の代わりに pull_r
GitHub - nektos/act: Run your GitHub Actions locally 🚀
"Think globally, act locally" Run your GitHub Actions locally! Why would you want to do this? Two reasons: Fast Feedback - Rather than having to commit/push every time you want to test out the changes you are making to your .github/workflows/ files (or for any changes to embedded GitHub actions), you can use act to run the actions locally. The environment variables and filesystem are all configure
GitHub Actions入門 ── ワークフローの基本的な構造からOIDCによる外部サービス認証まで - エンジニアHub｜Webエンジニアのキャリアを考える！
GitHub Actions入門 ── ワークフローの基本的な構造からOIDCによる外部サービス認証まで GitHubが公式に提供するGitHub Actionsは、後発ながらよく使われるワークフローエンジンとなっています。本記事では、藤吾郎（gfx）さんが、典型的なCI/CDのユースケースに即したワークフローの設定と管理について解説するとともに、注目されているGitHub OIDC（OpenID Connect）の利用についても紹介します。 GitHub Actionsは、GitHubが提供するCI/CDのためのワークフローエンジンです。ワークフローエンジンは、ビルド、テスト、デプロイといったCI/CD関連のワークフローを実行し、定期実行するワークフローを管理するなど、開発におけるソフトウェア実行の自動化を担います。 ▶ GitHub Actions - アイデアからリリースまでのワーク
WordPressをMarkdownで執筆、あるいはMarkdown→HTML変換とGitHub Pagesの自動更新 | IIJ Engineers Blog
はじめましての方ははじめまして、2020年のアドベントカレンダーをご覧になってくださった方はお久しぶりです、クラウド本部の坂口です。 私は普段、クラウドサービスのフロントエンド開発からOSイメージのメンテナンス、サービスの運用などをメインに行っています。 2020年12月にアドベントカレンダーで投稿した 我らの時代のコンテナデプロイ – Nomad, Consul, Vault はお楽しみいただけたでしょうか。 実はこの記事を執筆する際、様々な趣向を凝らしていました。今回はそれをご紹介いたします。 MarkdownとWordPress エンジニアたるもの文章はMarkdownで書き、Gitでバージョン管理したいですよね。 しかしWordPressでMarkdownを利用するには、WordPress5.0のGutenbergエディタを使うかプラグインを導入する必要があります。 Gutenbe
インフラのリリース自動化戦略とその行き着く先 - Cybozu Inside Out | サイボウズエンジニアのブログ
こんにちは、@ueokandeです。 本番リリースってドキドキしますよね。 本日はkintone.comのリリース自動化と、その戦略についてお話します。 kintone.comのCI/CDパイプライン kintone.comのインフラ構成はモノレポで管理しており、AWSの構成や、Kubernetes上にデプロイするサービスなどが1つのレポジトリに存在します。 現在のkintone.comは、開発環境、ステージング環境、本番環境の3つがあります。 適用タイミングをずらすことによる環境間の乖離を防ぐため、各リリースはすべての環境に適用することとしました。 開発環境でしばらく寝かせたい変更は、機能フラグやカナリアによって切り替えます。 CI/CDパイプラインは以下のようになっています。 それぞれの環境に順に適用し、本番環境適用後にテストが通れば無事リリース完了です。 kintone.comのCI
個人gemのCIをほぼ全部Travis CIからGitHub Actionsに移行した - くりにっき
2日間で30個くらいのリポジトリでGitHub Actionsに移行したのでメモ tl;dr; モチベーション GitHub Actionsを選んだ理由 GitHub ActionsでgemのCIをするための設定 2020/1/4 0:40追記 weekly build 公式のactions/setup-rubyではなくmasa-iwasaki/setup-rbenvを利用 ボツ案：Dockerイメージのrubyを使う masa-iwasaki/setup-rbenvを利用 setup-rbenvを使う場合の注意点 Travis CIのallow_failuresをGitHub Actionsでも実現する GitHub ActionsでRuby 2.3以下をビルドする Gemfile.lockをコミットしないリポジトリでもキャッシュを保存したい GitHub Actionsの不満点 ジョブ
circleci-bundle-update-prをGitHub Actionsで動かせるようにした - くりにっき
投げたPRはこちら github.com 動機 とある事情でCI用途のパーソナルアクセストークンを撲滅したかった件の一環です。 解説 GitHub Actionsはジョブ実行時に自動でアクセストークンをセットしてくれて便利なんですが、API実行の許可は付与されていても git push に対する許可が与えられていませんでした。 具体的には下記がGitHub Actionsだとエラーになります。 https://github.com/masutaka/circleci-bundle-update-pr/blob/v1.16.1/lib/circleci/bundle/update/pr.rb#L104-L111 そこでシステムの git で git commit と git push してる部分をAPIで置き換えた感じです。 circleci-bundle-update-prをGitHub
CIマニアから見たGitHub Actions(Beta)の使い所 - くりにっき
1ヶ月くらい使って勘所が見えてきたのでメモ メリット 1リポジトリ辺り20並列までジョブを並列実行できる ジョブ実行時はアクセストークンが勝手に設定されている マトリクステストがやりやすい 実際にGitHub Actionsに移行したプロダクト zatsu_monitor activerecord-compatible_legacy_migration index_shotgun デメリット yamlのanchorが使えない マトリクステストだとSlack通知がつらい 合わせて読みたい メリット 1リポジトリ辺り20並列までジョブを並列実行できる これに尽きる。 CircleCIにしろTravis CIにしろorganization(user) *1単位で並列数が縛られているため、例えば同じuserの他のリポジトリでジョブが詰まっていると別リポジトリではqueueが詰まってジョブが実行され
Google、「Cloud Build」発表。ビルド／テスト／デプロイの実行をマネージドサービスで提供、1日あたり120分まで無料。GitHubと提携も － Publickey
Googleはクラウド上でソースコードのビルド、テスト、デプロイなどを自動的に実行してくれるマネージドサービス「Cloud Build」を発表。あわせてソースコードのリポジトリとしてGitHubとの提携も発表しました。 Cloud Buildは、クラウド上でDockerコンテナを利用してソースコードをビルドし、自動テストを行い、コンテナプラットフォームなどへデプロイするプロセスを自動的かつ高速に実行してくれるマネージドサービスです。 マネージドサービスのためセットアップや運用の手間はかからず、自動的にビルド処理がスケールアウトするため高速に実行されるなどの特長を備えています。 ソースコードのリポジトリとして、Google Cloud Source RepositoriesやGoogle Cloud Storageにアップロードしたソースコードなどを利用可能。GitHub Marketpla
reviewdog を飼ってコードレビューや開発を改善しませんか - haya14busa
GitHub: haya14busa/reviewdog: A code review dog who keeps your codebase healthy 英語記事: reviewdog — A code review dog who keeps your codebase healthy – Medium reviewdog というlinter などのチェックツールの結果を自動で GitHub の Pull Request にコメントしたり， ローカルでも diff の結果から新たに導入されたエラーだけを表示するようにフィルタリングできるツールを作りました． 英語記事 を Medium に書いたし，README も書いたので 日本語記事はまぁいらないかなぁと思ったけど，柄にもなく Vim 関連以外で普通に便利ツールを書いてしまって，これは日本語でも簡単に共有しようかなぁと思いこの記事
DevOps & Platform Engineering Suite
Mix clouds, VPS, bare metal, CDNs. Stay free from vendor lock-in. Delightful DX from Shopify and Wordpress deployments to GitOps and IaC-heavy workflows. Deploy to 1000s of targets. Deploy only what has changed. Agent & agentless deployments. One-click rollback. Manual approvals & RBAC. Targets & tunnels management. Bring your own CI/CD or use our cache-optimized pipelines. Simultaneously design w
Infrastructure as Code - naoyaのはてなダイアリー
今年の3月に 入門Chef Solo - Infrastructure as Code という本を書いた。 その名の通り Chef の入門書なのだけど、このサブタイトルは "Configuration Management Tool (構成管理ツール)" でもなく "Provisioning Framework (プロビジョニングフレームワーク)" でもなく、はたまた "Automated Infrastructure (自動化されたインフラ)" でもなく、"Infrastructure as Code" にした。 この一年で Chef や Puppet にはずいぶんと注目が集まった。おそらく、AWS をはじめとするクラウドサービスがより広いユーザーに浸透したことで仮想化環境が前提になって、以前よりも頻繁にサーバーを構築し直したりする機会が増えたとかその辺がひとつ理由として挙げられると思う
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
【個人開発】キリ番を祝ってくれるGithub Actionsをリリースしました🎉【Go】 - Qiita
Improving GitHub Deployments with Merge Queue
GitHub - reviewdog/reviewdog: 🐶 Automated code review tool integrated with any code analysis tools regardless of programming language
GitHub - actions/runner-images: GitHub Actions runner images
Coveralls.io - Test Coverage History and Statistics