Github Actions上とローカルMac上のmakeタスクの挙動が異なっていてプチハマりした件
タスクランナーとしてmakeタスクをよく利用しています。 その際、ローカルのMacで問題なく動くのに、GitHub Actions上で異なる動作になっていてプチハマりしてたのでメモします。 なお、GitHub Actionsで利用しているDocker Imageは ubuntu-latest です。 makeタスクの内容 docker composeのサービス起動待ちのために以下のようなワンライナーのタスクを作ることがあります。 [1] 以下は localhost:8080の疎通ができるまで1秒スリープしながら 600回繰り返す（おおよそ最大10分待つ） という何のことはないタスクです。 waiting-for-service: @echo "waiting for service ..." @for i in {0..600}; do if [ `curl -fs http://loca
Makefileの代わりにnpm scripts+zxを使う - 詩と創作・思索のひろば
そこそこの規模があるプロジェクトで実行すべきタスクを定義するとき、初手として Makefile を使いがち。 Pros make は事実上どんな環境にもあることを期待してよい シェルで実行されるコマンドをそのまま書ける タスクの依存関係が明示できる Cons make では positional arguments が使えない 少し複雑なことをしようとすると Makefile 専用の文法を覚える必要がある 現代では、ファイルベースのタスクの依存関係は make が発明されたころほどは必要ではない Docker とか Go とか Webpack がよしなにしてくれることが多い 例: docker compose のラッパー ちょっとしたコマンドのラッパーを書きたいことがある。Makefile を書きはじめたらすべてのエントリポイントを make にしたい。ということで、以下のような Make
Go で使う Makefile の育て方
Go を使ってプロダクトを作る時、Makefile を使ってビルドを指定することが多いです。 理由としては、 バージョン情報などを埋め込むのに都合がいい 複数のバイナリを吐き出す時に都合がいい Go のビルドオプションを指定するのにいろいろあって整理しておきたい 事前にコードジェネレータで書き出す部分があり、それを考えると Makefile などで整理したい などなどです。なので今回はプロジェクトが大きくなっていく中でどういう Makefile の書き方をしているか、というのをご紹介しようと思います。 サンプルとして、今回のプロジェクトでは gRPC を使ったチャットサービスのサーバーとクライアントを作ることにします。リポジトリは https://github.com/rosylilly/gochat に置いておきました。 Step 1. バージョン情報を埋める 今回はサーバーとクライアン
Makefileの書き方 - $ cat /var/log/shin
まえがき その昔、Makefileの書き方という非常にわかりやすいMakefileの入門ページがあったのですが、seiichirou氏の卒業（？）とともにページが消えてしまいました。 私も大変お世話になったページだった、というかこれからもお世話になりそうなので、そこでWebArchiveから引っ張りだしてきたものを、はてな記法で書き直したものがこの記事になります。 元々自分用に書き直したのですが、せっかくなので公開してみます。 なので、以下の著作はseiichirou氏に帰属します*1。 Makefileの書き方 はじめに ここでは、Makefileの中でもGNU makeにかぎって説明します。 makeって何？ ソースファイルを分割して大規模なプログラムを作成していると、コマンドでコンパイルするのが面倒です。また、一部のソースファイルを書き換えただけなのに全部をコンパイルし直すのは時間の
Makeについて知っておくべき7つのこと | POSTD
Make は、様々なタイプのファイルのビルド作業を自動的に行ってくれるシンプルかつ強力なツールです。しかしながら、makefileを書く際に問題にぶち当たるプログラマもいれば、Makeの基本知識がないことで、既存のものを再発明してしまうプログラマもいます。 Makeの働き デフォルトでは、Makeは一番目のターゲットから開始します。このターゲットのことをデフォルトゴールと呼びます。 Makeはカレントディレクトリのmakefileを読み込み、一番初めのルールで処理を開始します。しかし、Makeが完全にこのルールを処理する前に、ルールが依存するファイルのためのルールを処理しなければなりません。各ファイルそれぞれは、自身のルールに従って処理されます。 実はこれは、各ターゲットの再帰的アルゴリズムになっています。 ターゲットをビルドするルールを見つける。ルールがないようであれば、Makeはうまく
【翻訳】Web世代のデベロッパーのためのmake - MOL
Original：Make for the Web Generation （2015-02-28）by Casper Beyer イントロ JavaScriptの普及に伴いビルドツールが盛んだ。人気なものをいくつか挙げれば、grunt、gulp、slush、broccoliやbrunchなどがあるが、結局、名前をつけただけにすぎない。 多かれ少なかれ、これらのツールはファイルコピーからzipファイル作成のようなシンプルなタスク処理でさえ、すべてプラグインに依存しているので、それらのタスクを実行するためにプラグインを必要とするだろう。 これらのツールは理想論的には大きな柔軟性をもたらすものとされているが、実際はUNIXのエコシステムをただ複製しているだけにすぎない。このために君のプロジェクトは早々に、大きな開発依存性のバンドルを持つことであろう、そして、やっているタスクは単なる普通のコピー、
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - tj/mmake: Modern Make