actions/artifacts@v4アツい、CIの話題多め、おまけあり｜Productivity Weekly(2023-12-20号)
こんにちは。サイボウズ株式会社 生産性向上チームの平木場です。 僕たち生産性向上チームは毎週水曜日に Productivity Weekly という「1 週間の間に発見された開発者の生産性向上に関するネタを共有する会」を社内で開催しています。 本記事はその時のネタをまとめたものです。 2023-01-25 号から、基本的に隔週で連載することとしました。たまに単独でも投稿するかもしれません。 今週は 2023-12-20 単独号です。 今回が第 137 回目です。過去の記事はこちら。 生産性向上チームのマスコットキャラクター、セイサンシャインくん爆誕 news 📺 GitHub Actions - Artifacts v4 is now Generally Available - The GitHub Blog actions/upload-artifactとactions/downloa
GitHub Actionsのサードパーティーマネージドランナーの紹介 - いけだや技術ノート
この記事は はてなエンジニア Advent Calendar 2023 の 2024年1月4日 の記事です。 GitHub Actionsの実行環境であるランナーには、GitHubが提供するGitHub ホステッド ランナーと、自分でランナーを用意・管理するセルフホステッド ランナーの大きく二種類があります。 最近はGitHub ホステッド ランナーにもラージランナーが用意されるようになり、ある程度ランナーのスペックを選べるようにもなりましたが、他のCIサービスと比べてもスペックの割にコストが高めである感じは否めません。一方でセルフホステッド ランナーにはスペックを自分で調整できる自由度がありつつも、管理する手間とコストが掛かってきます。 こうした隙間を突くように、サードパーティーによるマネージドなセルフホステッド ランナーを提供するサービスが増えつつあります。基本的には runs-on:
GitHubActionsでmatrixの値を動的に扱う - notebook
実際使うかと言うとどうなんだろうという気もするが、できるの知らなかったので残しておく いきなりサンプルコードだがこれだけで理解はできると思う .github/workflows/dynamic-matrix.yml name: dynamic matrix on: [push] jobs: set-matrix: runs-on: ubuntu-latest outputs: something: ${{ steps.set-matrix.outputs.value }} steps: - name: make values id: set-matrix run: | echo '["hoge","fuga"]' | jq -c list=$(echo '["hoge","fuga"]' | jq -c) echo "value=${list}" >> $GITHUB_OUTPUT exe
Sample: Use Python Poetry cache on GitHub Actions workflow
use_python_poetry_cache_on_github_actions_workflow.yml �C#��U Аh��U name: Use Python Poetry cache on GitHub Actions workflow on: push: branches: - main env: PYTHON_VERSION: "3.11" POETRY_VERSION: "1.4.2" POETRY_URL: https://install.python-poetry.org jobs: use_cache: runs-on: ubuntu-latest steps: - name: Checkout uses: actions/checkout@v3 - name: Set up Python ${{ env.PYTHON_VERSION }} uses: action
GitHub Actionsって何？触ってみて理解しよう！入門・逆引きリファレンス - Qiita
ある日のこと 「さーて、今日もGitHubにコミットをプッシュしていくぞ〜〜」 「ローカルでコミットした変更をgit push origin mainして、、」 「github.comのレポジトリを見にいくと、、お！反映されているな！Initial Commitってちゃんと出ているぜ！」 「そういえば、いつも気にしていなかったけどActionsタブってのがあるな？これってなんだ？」 これがGitHub Actionsです。レポジトリごとに用意されていて、Actionsタブから管理、確認することができます。 「ほ〜。GitHub Actionsっていうのか・・なんのためにあるんだろう？ここで何ができるの？」 GitHub Actionsとは GitHub ActionsはGitHubがサービスの一環として提供する、ワークフロー自動化サービスです。 簡単に言えば、「開発している時にやりたいこと
GitHub Actions 逆引きリファレンス
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
GitHubActionsで自動ビルドする際、Tokenのスコープでつまづいた話
経緯 VSCodeからGitHubActions用のymlファイル（.github/workflows/blank.yml）を編集する際に下記のエラーが発生 refusing to allow a Personal Access Token to create or update workflow `.github/workflows/blank.yml` without `workflow` scope) GUI上では特に問題なく編集することができていた 原因 理由は記載の通りで、発行しているアクセストークンにworkflowの権限が付与されていないためエラーが発生していました なぜこんなことでつまづいていたかというと、VSCode上では「error: failed to push some refs to 'https://github.com/XXX/XXX'」しか表示されていなかっ
GitHub Actions上で独自のワークフローを構築しやすくするための仕組み - Pepabo Tech Portal
本エントリはGMOペパボエンジニア Advent Calendar 2021の25日目のエントリです。メリークリスマス！ はじめまして、技術部技術基盤チームの@k1LoW と申します。最近はYouTube Musicの「おすすめのアーティスト」をふらふらと漂流するのが好きです。その漂流で見つけた Nubiyan Twist がカッコいいです。 GMOペパボではGitHub Enterprise Server (以下、GHES）を利用しており、CI/CD基盤としてGitHub Actionsを活用しています。 本ブログでも様々なGitHub Actions活用事例を紹介しています。 #GitHub Actions に関する記事一覧 手動で実施していた業務やタスクをGitHub Actionsのワークフローとして構築しなおす GMOペパボではGitHub Actionsをいわゆる「CI/CDの
Terraformのレビューを自動化するために、Conftestを導入してGithub ActionsでCIまで設定してみる - nariのエンジニアリング備忘録
はじめに 対象読者 OPA/Rego/Conftestとは Regoでポリシールールを記述して、ルール自体のテストも記述しながらCIへ組み込んでいくまで Conftest(OPA/Rego)のセットアップ 前提知識: Terraform plan 結果の構造 ConftestでTerrafom resource tag ルールを書いてみる ConftestでRegoで書いたルール自体のテストを書いて、実行してみる Conftestを実行するCIをGithub Actionで整備する Conftest/Regoで書いたポリシールール自体のfmt/verifyのCIの設定 Conftest testでTerraform plan結果をテストするCIの設定 終わりに 参考文献 English Version: dev.to はじめに メリークリスマス。eureka, inc. でSREをやってい
GitHub Actionsの手動実行パラメータのUI改善について速報で解説する
11/10に突如素晴らしいアップデートが来たので、興奮冷めやらぬうちに公式よりちょっとだけ詳しい解説を書きます。 GitHub Actionsは素晴らしいCI/CDサービスであり、特にpush, pull-request, その他あらゆるGitHub上の行動をトリガーにしてワークフローを起動させる設定を簡単に書くことができます。しかし、手動でワークフローを起動させる機能の追加は他のトリガーに比べて後発でしたし、パラメータを入力するための機能やUIが少々貧弱と言わざるを得ないものでした。 一方、古より存在するJenkinsはpush, pull-requestなどの自動トリガーを設定するのは難易度が高かった[1]反面、手動でジョブを起動する機能やUIは充実していました。基本の自由テキスト以外に、プルダウンによる選択、booleanのチェックボックス、Jenkinsに登録したシークレットからの
Github Actions チートシート
概要 何度も調べて何度もテストしたりしたので、多用するものをまとめていきたい。 項目 push時に実行 // feature/aaaで動く。 feature/aaa/bbbでは動かない on: push: branches: - feature/* // feature/aaa, feature/aaa/bbbで動く on: push: branches: - feature/** // なにかしらのtagがpushされたときに実行、branchのpushは無視 on: push: tags: [ '**' ] branches-ignore: [ '**' ] // 指定したpathの変更だけでは実行しない on: push: branches: - main paths-ignore: - '*.md' - 'docs/**' on: workflow_dispatch: inputs
GitHub Actionsの知見ご紹介 - Masteries
今更ですが, ここ最近ちまちまとGitHub Actionsをしています. github.co.jp 個人的にはこういうのイジるの大好きなので, 新しいおもちゃをもらった子供のようにはしゃいでいます. 今回は, その中で知った知見などを雑多にご紹介します. Pull Requestでコケた時にRe-run jobsするとactions/cacheアクションが正常に動作しない GitHub Actionsには, 依存ファイル(例えばPerlならlocalとか, Node.jsならnode_modulesとか...)をキャッシュする, actions/cacheアクションが公式から提供されています. github.com このアクションを使っていて, かつon: pull_request のようにしてPull Requestをフックとしてワークフローを実行するとき, Re-run jobs(再
Go製ソフトウェアのCIやリリースをGithubActionsで行う
Go で書いた CLI ツールのリリースは GoReleaser と GitHub Actions で個人的には決まり を読んで、自分もどうやっているのか書いておこうと思ったので書く。 CIでテストを実行する これはまあ、素朴にやる。テスト自体はMakefileに隠蔽しておくと手元でもCIと同じテストを実行できて便利。 --- name: CI on: [push] jobs: run_test: name: Go Test runs-on: ubuntu-latest steps: - name: Set up Go 1.13 uses: actions/setup-go@v1 with: go-version: 1.13 id: go - name: Check out code into the Go module directory uses: actions/checkout@v
GitHubの新機能「GitHub Actions」で試すCI/CD | さくらのナレッジ
GitHubが2019年11月、新機能「GitHub Actions」を正式に公開した。GitHub上のリポジトリやイシューに対するさまざまな操作をトリガーとしてあらかじめ定義しておいた処理を実行できる機能で、今まで外部サービスとの連携が必要だった自動テストや自動ビルドなどがGitHubだけで実現できるようになる。今回はこのGitHub Actionsについて、機能の概要や基本的な使い方などを紹介する。 GitHubだけでCI/CD的な機能を実現できる「GitHub Actions」 昨今では、ソフトウェア開発におけるさまざまな工程を自動化するような技術の開発や普及が進んでいる。その1つに、CI（Continuous Integration、継続的インテグレーション）やCD（Continuous Delivery、継続的デリバリー）と呼ばれるものがある。CIはソフトウェアのビルドやテストを
Go で書いた CLI ツールのリリースは GoReleaser と GitHub Actions で個人的には決まり - tellme.tokyo
Go で書いた CLI ツールのリリースは GoReleaser と GitHub Actions で個人的には決まり February 4, 2020 lt;dr GoReleaser と GitHub Actions を使うと簡単にビルドしたバイナリを作ってアップロードできる。 2つの YAML を書いてリポジトリにコミットする .github/workflows/release.yml .goreleaser.yml git tag して push する バイナリがリリースされる 専用のツールをローカルにインストールする必要はない。 本題 前に、Go のコマンドラインツールを簡単にリリースする | tellme.tokyo というブログを書いた。 それよりももっと楽になったので紹介する。 基本的にこのページで紹介する方法では 2 つの YAML をリポジトリに置くだけで終わる。 ロー
GitHub Actionsのcheckoutアクションがv2でいろいろ変わって便利になっていた - いけだや技術ノート
GitHub Actionsをそこそこ使っている今日この頃です。さて、Actionsといえば普遍的に使う、リポジトリをチェックアウトする actions/checkout がありますが、このアクションがv2になり、色々と挙動が変更・改善されてい便利そうなのでいくつかご紹介。 https://github.com/actions/checkout/releases/tag/v2.0.0 https://github.com/actions/checkout#whats-new fetchのdepthがデフォルトで1になり、フェッチが速くなった チェックアウトの際に使用されたActions発行のトークンがgitのconfigに永続化され、リモートへのpushなどの操作が設定要らずでできるようになった ブランチのチェックアウト時にはローカルブランチを作るようになった（detached HEADに
GitHub Actions ことはじめ - tech.guitarrapc.cóm
GitHub Actions 以前調べたのですが、いろいろあって個人プロジェクトでサクッとビルドするのみに使っていました。 今回改めて調べを進めたのでメモ。 幾つかのリポジトリを GitHub Actions に移行したけど、記事にしようとまとめてたらやった内容以上に調べることになってめちゃめちゃ時間かかった。 目次 目次 TL;DR トレンド GitHub Actions の基本 使用条件 使用制限 料金 ホストランナーの指定 ハードウェアリソース インストールされるツール IP OSの選択 実行権限 ファイルパス 環境変数 シークレット GITHUB_TOKEN コンテキスト Artifact トリガーイベント Cache Actions 通知 YAML Getting started YAMLシンタックス on env jobs.<job_id>.needs jobs.<job_id
個人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の不満点 ジョブ
僕がOSS導入時に気にしてること - くりにっき
前置き 観点 GitHubやGitLabなどのリポジトリの場合 https://rubygems.org/ https://hub.docker.com/ 共通 (2019/12/29 11:30追記) 2019/12/29 11:30ブコメレス 前置き 社のesaに投下したものの反応が薄くて寂しいので全体公開 他人が作ったOSSを使うにあたって、もしあまりメンテされないOSSを使うと結局別のOSSに乗り換える必要があっておつらいので、僕がどんな観点でOSSを選択してるのかをまとめました あくまで僕が見ている観点なので異論は認める 観点 GitHubやGitLabなどのリポジトリの場合 Star数 多ければ多いほどいい 放置されてるIssueやPRの数 少なければ少ない方がいい オープンになってるPRがたくさんあってもちゃんとレビューされてマージされてるのであればいいんだけど、放置されてる
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - mvdan/github-actions-golang: GitHub Actions as CI for Go
