Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

GitHub Actions: Self-hosted runners now support Apple M1 hardware Actions runner support for Apple silicon hardware, such as the M1 chip, is now generally available. This provides teams with the capability to run self-hosted macOS workflows in a macOS ARM64 runtime. Now the Actions runner supports M1 and the ARM64 runtime meaning developers can run it on their own M1 or M2 hardware. Based on initi
突然ですが、git-pr-releaseのなんちゃってコラボレーターである私が僭越ながら、その王道の使い方を皆様に伝授していきます。何番煎じかの記事ではありますが、現代の、特にGitHub Actions出現以降の使い方をまとめたいというのが動機です。 https://github.com/x-motemen/git-pr-release https://rubygems.org/gems/git-pr-release git-pr-releaseはGitHubを業務開発で利用している場合に便利なツールで、デフォルトブランチにマージされたpull requestをリリース項目として一覧し、それをpull request化してくれるものです。これにより以下のことが実現できます。 リリース項目が一覧されることによるリリース内容の明確化 マージボタンによる明快なワンクリックデプロイの実現 pul
本記事の内容は執筆時点(2022/6/21)での内容です。今後のアップデートにより結果が変わる可能性があります。 Terraformのコード(HCL)をスキャンすることができるSnyk IaCをGitHub Actionsから利用する方法を紹介します。またSnyk IaCのほかにもTerraform用のOSSスキャンツールであるtfsec、terrascanも試してみて、それぞれのスキャン結果についてみていこうと思います。 スキャン対象のコード 本記事においては、TerraformでAWSのサービスをプロビジョニングするシナリオで進めていきます。 具体的には以下のような構成でAWSを構築します。 1つのVPCと1つのパブリックサブネット パブリックサブネットにEC2を配置 EC2にセキュリティグループを割り当て、インターネットからのssh(22ポート)を許可 スキャン対象のコードは以下の通
name: deploy-js on: push: branches: [ master ] paths: - "client/src/**" env: AWS_ROLE_ARN: ${{ secrets.AWS_ROLE_ARN }} AWS_REGION: ${{ secrets.AWS_REGION }} DISTRIBUTION: ${{ secrets.DISTRIBUTION }} jobs: build: runs-on: ubuntu-latest strategy: matrix: node-version: [18] steps: - uses: actions/checkout@v3 - name: Use Node.js ${{ matrix.node-version }} uses: actions/setup-node@v1 with: node-version
はじめに リリース時にリリース内容をコメントする GitHub Actions を作ったので紹介します。 リポジトリ Release Menu 動作 具体的な動作としては、リリースブランチ (名前が release で始まるブランチなど) からプロダクションブランチ (main ブランチなど) にマージする PR を作成した際に、その中に含まれる変更内容の PR 一覧をリリース PR のコメントに残します。 また、オプションとして Slack に投稿する機能も実装しています。 使い方 YAML ファイルをリポジトリに置くだけで動作するので導入はとても簡単です。 # .github/workflows/release-menu.yml name: "Release Menu" on: pull_request: types: [opened] jobs: release-menu: if:
こういうのを作りました。 ジョブに紐付いたPull Requestへのリンクが表示される 行ったこと: リンクを生成するジョブを1つ生やした 綺麗な表示はStep Summary機能 (後述) の力を借りている ジョブ実行画面からPull-Reqに戻りたい GitHub Actionsのジョブ実行画面には、その実行元となったPull Requestへのリンクが存在しないため、困っていた。 よくあるシチュエーション: Pull Requestを見るとジョブがコケていた 様子を見に行くうちに履歴がどんどん深くなる -- ジョブ画面内での遷移はどんどんヒストリが積まれる Pull Requestに戻れなくなってしまう この話を同僚にしたところ共感の嵐だった。したがって隠れた需要がありそうだということが判明し、うまくやる方法を考えることにした。 結果、GitHub Action上でPull-Req
「GithubActionsでaws-nukeを定期実行したい。」 AWSリソースの一括削除に便利なaws-nukeですが、定期実行できたらさらに便利ですよね。 今回は、GithubActions上でaws-nukeを定期実行する方法を紹介します。 やってみた フォルダ構成 . ├── .github │ └── workflows │ └── aws-nuke-run.yaml # aws-nukeをGithubActions上で実行する ├── docker-compose.yml └── nuke-config.yml #aws-nuke用のconfigファイル IAMロールを作成 GithubActionsからAWSリソースを作成するために、IAMロールを作成します。 IAMロールの権限は、削除したいリソースによって変わります。 私はIAMユーザーなども削除したかったため、Admi
docker compose on GitHub Actions 昨今ではDocker(コンテナ)を使った環境整備が主流になってきています。アプリケーションの実行環境自体をコード化できるため、開発環境間の差異や、本番環境の差異を吸収し、アプリケーションの開発に集中することができます。 一方、CIとDockerの相性はなかなかに良くないです。Dockerの肝はイメージやレイヤーのキャッシュにより、初回のダウンロード以降は爆速に使えることですが、環境がある程度リセットされてしまうCI環境で愚直にDockerを動かすコードを書くと数百MB単位のイメージのダウンロード、ビルドが毎回走ることになり、Dockerを準備する処理でCIの処理の大半が使われてしまうこともままあります。 今回はDockerによる環境のカプセル化の恩恵を受けつつ、GitHub Actionsでdocker composeを動か
はじめに Checkovとは ローカルPCでの使い方 インストール (留意事項)レベルアップ 静的解析のやりかた 静的解析の実行方法 指摘事項のスキップ方法(Terraformのオブジェクト単位) 指摘事項のスキップ方法(ルール単位) GitHub ActionsへのCheckovの組み込み はじめに Terraformコードのセキュリティーチェックを行う必要があり、IaC用の静的コード解析ツールであるcheckovをGitHub ActionsのCIに組み込んでみた時のメモです。 最初にcheckovをローカルで実行する場合のやりかたを説明して、最後にActionsへの組み込み方法を説明します。 Checkovとは Checkovは、Infrastracture as code(IaC)コード用の静的コード解析ツールです。Checkovを利用することで、セキュリティやコンプライアンスの問
この記事は、Qiita エンジニアフェスタ 2022 GitHub Actions の自分流の使い方をシェアしよう の参加記事です。 はじめに 僕は個人の作業環境の 1 つとして EC2 のインスタンスを立てているのですが、コストをなるべく書けたくはないので、使用するとき以外はインスタンスを停止しています。 ですが、インスタンスの停止を忘れてしまうことが多々ありました。 それから「自動で停止するようにしたいなぁ」と思い、AWS CLI でインスタンスを停止する GitHub Actions の workflow を用意して、schedule イベントでトリガーさせることにしました。 上記のようにした理由は、 自由が効く cron サーバーを用意するのはめんどくさい(というか cron サーバーを立ててる時点で本末転倒?) です。 あとは単純に楽しそうだなという好奇心です。 以下で紹介してい
はじめに こんにちは、イトーです。 Github Actions はこれまで PR を出した際にテストをかけてその成否でマージをブロックしたり、タグを打つとかマージとか何かしらのイベント発生をトリガーとしてアプリケーションをビルドしてクラウドにデプロイしたりするために使ってきました。要するに CI/CD ですね。チェックのためにテストをかけるとかテストステージや本番ステージにデプロイを行うとか定型的な作業をガッツリ削れることになり、怠惰なるエンジニアとしては大変ありがたい限りです。 さて、今回はこの「楽できる仕組み」を機械学習に持っていけないかと思いまして、最近 GA した Azure Machine Learning CLI v2 と Github Actions を組み合わせる方法を思いつきました。 機械学習もソフトウェア開発の一種、もっと言うとデータから関数を作成するある種の自動プロ
はじめに 本記事は、アジャイル開発手法におけるQAの参考になれば、と作成しました。 開発、QA、また今後、それらに携わっていく方々の即戦的知識になればと思います。 また、本記事で作成したソースコードは下記に公開しています。 https://github.com/EIKINAKAYAMA/cypress-demo そもそもテストって? システム開発では、システムがリリースされるまで、 作成された開発物に問題がないかを色んなテストでチェックします。 UIテスト ブラックボックステスト 負荷テスト リグレッションテスト 退行テスト 受け入れテスト アドホックテスト etc... 上記は一部を載せていますが、まだまだ沢山あります。 会社や組織によって呼び方が変わったり、テストというよりもテスト手法だったり、同じようで厳密には内容が異なったりと多種多様のテストが存在し、必ずしも全てのテストを実施して
1.この記事の立ち位置#自分がいつも調べていること、忘れがちな Tips や小ネタを列挙していく。そのため、網羅性は重視しない。 というのも、なにか調べていていろいろ読み漁った挙げ句、1周回って行き着くところは GitHub Actions の公式ドキュメントであり、たとえば Workflow の書き方は以下のページをよく開いている。 Workflow syntax for GitHub Actions - GitHub Docs それでも、公式ドキュメントで参照したい箇所を引っ張るための用語を知るまでに苦労することが往々にあり、この記事が、公式ドキュメントで参照したい箇所を導くための助けとなればと思い、書いていく。 2.Step と Job と Workflowの違いアレコレ#2-1.Step と Job と Workflow の違いの一行まとめ#Step < Job < Workflo
You can now enable debug logging when you re-run jobs in a GitHub Actions workflow run. This gives you additional information about the job's execution and its environment which can help you diagnose failures. To enable debug logging, select "Enable debug logging" in the re-run dialog. You can also enable debug logging using the API or the command-line client. For more details see Re-running workf
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く