GitHub Actionsで特定の条件の時だけenvironmentを設定したい - くりにっき
tl;dr; environment を三項演算子でいい感じにする モチベーション TerraformのワークフローをGitHub Actionsで動かしてるんだけど、terraform apply した時（具体的にはmainブランチか手動でのbuild実行時 *1 ）のみ environment をセットしてDeployments *2に通知したかった。（ terraform plan （Terraformのdry run）ではDeploymentsには通知したくない） 実装例 こんな感じ。 environment: ${{ ((github.ref == 'refs/heads/main' || github.event_name == 'workflow_dispatch') && 'terraform-apply') || '' }} github.com 分かりづらいんですが t
1Passwordを使って、ローカルにファイル(~/.configや.env)として置かれてる生のパスワードなどを削除した
1Passwordを使って、ローカルにファイル(~/.configや.env)として置かれてる生のパスワードなどを削除した 最近、コミットはされないがローカルのディレクトリに置かれている.envのようなファイルから生のパスワードやAPI Tokenを削除しました。 これは、ローカルでマルウェアを実行した場合に、ローカルに置かれている生のパスワードやAPI Tokenを盗まれる可能性があるためです。 最近は、npm install時のpostinstallでのデータを盗むようなマルウェアを仕込んだりするソフトウェアサプライチェーン攻撃が多様化しています。 Compromised PyTorch-nightly dependency chain between December 25th and December 30th, 2022. | PyTorch What’s Really Goin
docker/build-push-action v3.3.0で導入されたprovenanceオプションにまつわる問題 - chroju.dev
docker/build-push-actionのv3.3.0 で、 provenance というオプションが入り、デフォルトで有効化された。このオプションについては、 This may introduce issues with registry and runtime support (e.g. GCR and Lambda). という注意書きがされており、一部環境で問題が起きる可能性がある。GitHub Actionsでバージョンをマイナー、パッチバージョンまで指定せずに使っていた場合、自動的にこのバージョンが適用されるため、実際に問題になったという声もTwitterで散見され、自分も一部で引っかかった。 @GitHub Actions runner bumped @Docker buildx today, which has default provenance on. It's
docker/build-push-action@v3 + GCP のデプロイエラーを何とかした覚書
GCP 素人の私と、心優しい同僚たちが、デプロイエラーに立ち向かった覚書です。筆者が GCP 素人なので、語り口が素人くさいのはご容赦ください。 3 行まとめ 2023 年 1 月 14 日以降しばらくの間、GitHub Actions を用いて Cloud Run 等へデプロイする際に「コンテナイメージが見つからない」といった類のエラーメッセージが出たら、 docker/build-push-action@v3 の利用を疑ってみる provenance に未対応のレジストリを使っているのがわかったら、 provenance: false をインプットとして指定すると、治るかもしれない Cloud Run の場合、エラーメッセージが出た時点で異常な状態のリビジョンを作成してしまっている場合があるので、念のためチェックして、必要であれば異常なリビジョンを削除するとよい 2022.2.9 追記
CI/CDサービスのOpenID Connect対応 Dive Into - Lento con forza
これははてなエンジニアアドベントカレンダー2022 39日目の記事です。 昨日は id:nakaoka3 の ミーティングの時間になると勝手に議事録を開いてほしいでした 先日あった、CircleCIのインシデントのAdditional security recommendationsとして、OIDC Tokenを使うことが推奨されていました。GitHub ActionsやCircleCIなどのCI/CDサービスでは外部サービスへの認証を行うために、OpenID Connectに対応しています。OpenID Connect対応がされていることは知っていたのですが、OpenID Connectといえば、外部サービス連携をしてログインに使うイメージだと思います。たとえば、Googleの認証情報で、はてなアカウントにログインするなどといったようにです。僕の中で、ユーザー認証に使うOpenID Co
基本的な書き方とフォーマットの構文 - GitHub Docs
見出し 見出しを作成するには、1 つから 6 つの # シンボルを見出しのテキストの前に追加します。 使用する # の個数によって、見出しの階層レベルと書体のサイズが決まります。 # A first-level heading ## A second-level heading ### A third-level heading 2 つ以上の見出しを使用すると、GitHub では自動的に目次が生成されます。この目次には、ファイル ヘッダー内の をクリックするとアクセスできます。 各見出しのタイトルが目次に一覧表示され、タイトルをクリックして選択したセクションに移動できます。 テキストのスタイル設定 コメント フィールドと .md ファイルでは、太字、斜体、取り消し線、下付き、上付きのテキストで強調を示すことができます。 スタイル構文キーボード ショートカット例出力
エンジニア向け「GitHub Pages」を使った技術メモ公開のススメ - karaage. [からあげ]
技術メモにGitHubのGitHub Pagesが最適かも ちょっとした、公開してもよい技術メモ。今まで、はてなブログに書いてきました。Markdown記法も使えるし、書きやすいし、デザインも手軽にそこそこ良いのができるしと、個人的には中々良いと思っているのですが、以下のようなときに不都合があります。 画像以外のファイル(csvとか)をアップロードしたい 修正の差分履歴を残したい テーマごとに大量のサイトを作りたい ブログというほどでもないちょっとしたログとして使いたい 無料で何かよいのないかなーと思っていたのですが、GitHubの提供するホスティングサービスであるところのGitHub Pagesが中々良かったので紹介します。最近アップデートして更に便利になっているので、少し昔に使って不満を感じていた方も、再度試すと思わぬ発見があるかもしれません。。 あと、GitHubって何？という人は学
![エンジニア向け「GitHub Pages」を使った技術メモ公開のススメ - karaage. [からあげ]](https://cdn-ak-scissors.b.st-hatena.com/image/square/16a012df58cb51eb74e36a7b9909fb75b4f18235/height=288;version=1;width=512/https%3A%2F%2Fcdn-ak.f.st-hatena.com%2Fimages%2Ffotolife%2Fk%2Fkaraage%2F20170815%2F20170815164455.png)
composerでGitHub apiのアクセス制限対処法 - Qiita
経緯 Fuelphpインストール時にGitHub apiのrate limitに引っかかり、トークンを要求され、インストールが失敗しました。 以下その時のエラーメッセージ Could not fetch ~, please create a GitHub OAuth token to go over the API rate limit Head to ~ to retrieve a token. It will be stored in "/home/vagrant/.composer/auth.json" for future use by Composer. Token (hidden): 1日置いても解除されなかったので、tokenを取得、設定しました。 token取得方法 次のコマンドを実行します。 curl -u '[user name]' -d '{"scopes":["re
Composerでgit上のLibraryを使いたい時のメモ - Qiita
はじめに PHPのComposerでGit上のライブラリを使いたい時のメモです。 下記を見ればわかる https://getcomposer.org/doc/05-repositories.md#vcs のですが、Composer初心者には当たり前のお約束もわからなかったので残しておきます。 今回やりたかったこと 「とあるPHPのComposerライブラリ」をForkして今後ややカスタマイズしつつ使いたい なので、Github上でForkしてそれをcomposer経由で取ってきたい どうしたか こう書けばOKだった { "repositories": [ { "type": "vcs", "url": "https://github.com/yumemi/oauth2-server-php" } ], "require": { "bshaffer/oauth2-server-php": "
composer 導入をまじめに考える - Qiita
これは結構大きいPHPのプロジェクトに composer を導入する機会があったので、そのときに考えてたことや行ったこと、使い方などをメモするために書いた。 モチベーション 私達は PHP のパッケージの管理を管理する際は pear と git submodule を利用していた。これらのやり方は意外と長続きした。これらにはついて様々な問題を抱えており、ついに限界がきてしまった。 pear pear でパッケージを導入するには root 権限が必要なので、毎回インフラチームに導入を依頼するのが必要があった。 pear で導入されたパッケージについてバージョンを上げようとすると、全APサーバーで更新をかける必要があった。 これらの点から面倒だったのと、気軽に変更できないので、不要になったものも削除されることなく、放置されるのが問題だった git submodule こちらは pear とは異
GitHubでtagをmasterにする - ジムには乗りたい
概要 GitHub上のOSSをフォークして開発したい。 でも、フォーク元のmasterではなくtagから派生させたい。 ので自分のリポジトリ（フォーク先）ではtagをmasterにする手順。 手順 リポジトリをForkする GitHubから普通にForkするだけ tagを開発ブランチとしてpushする cloneした後、tagを確認する git tag -l tagからブランチを作成する git checkout -b ${ブランチ名} refs/tags/${タグ名} 作成したブランチをpushしておく masterブランチを削除する GitHubではdefaultブランチがmasterになっている。 そしてdefaultブランチは削除できないのでGitHubの画面から変更する。 変更先はtagから作成したブランチ。 [settings]→[branches]→[Default bran
中の人に聞いたGitHub flowの本当の使い方 - Qiita
背景 今日GitHubの中の人のLTを聞く機会があって本当のGitHub-flowを聞いてきたので 忘れない間にメモ GitHub-Flowのお約束 Masterにあるものは即座にデプロイ可能な状態に保つこと ブランチの上で必ず作業し、その生存期間を短くすること すぐにPRを作り、フィードバックやサインオフを求めること マージしたらすぐにデプロイすること 本当のGitHub-flow 中の人曰くよくマージしてからデプロイすると言っている人がいるらしい。 だが本当のGitHub-flowは違う。 本当のflowは PR作成 ⇩ 修正 ⇩ デプロイ ⇩ フィードバック ⇩ マージ らしい。 マージ前にデプロイすることでさらにユーザーに近いところでフィードバックを受けることができるとのこと。 ダメなら直ちにmasterに戻す。なので決まりごとの中にmasterは直ちにデプロイできる状態にあること
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Git・GitHubに隠された便利な機能 | GitHub Cheat Sheet（日本語訳） - Qiita
composerでGitHubのリポジトリからパッケージ追加する方法 - namaozi's memo