Docker Compose 1.27.0以降ではdocker-compose.ymlにversionを書く必要がなくなっていた - hogashi.*
あらすじ docker-compose.yml でトップレベルの version 要素を指定していると、 WARN[0000] (...)/docker-compose.yml: `version` is obsolete と表示される。インターネットを見ていくと version は指定しなくて良い、消したらいい、という記事がたくさん出てくるし、たしかに公式のドキュメントにも obsolete と書かれている Version and name top-level elements | Docker Docs。 Version top-level element (obsolete) The top-level version property is defined by the Compose Specification for backward compatibility. It is
雰囲気でDocker Composeを触っている状態から脱するために調べたこと（2023） - Activ8 Tech Blog
エンジニアの岡村です。 自分はサーバーがメインではなく、あまり業務でガッツリ触るわけでもないのですが、最近それなりに活用するようになってきました。しかし、ネット上の日本語情報を読んでいるだけではこれの書き方が正しいのかよく分からない、と悩むことが結構あったため、色々情報を漁ってみました。 この記事は、特に自分が気になった部分の調べた結果を記事に纏めてみたものです。対象読者はdocker-composeを雰囲気でupやdownは叩けるけどComposeファイルの書き方がよく分からんとなってる人です。 Docker Composeの概要とcompose.yaml、Compose Specの関係 compose.yamlの書き方は Compose Specに準拠すればOK Compose Specの場所 推奨のファイル名はcompose.yaml compose.yaml内にバージョンを記述する
「YAMLの本来の使い方」を仕様から読み取ってみる | Wantedly Engineer Blog
YAMLは「便利なJSON」として使われることが多い一方、その複雑性から落とし穴も多く、しばしば批判の対象になります。 なぜYAMLはそこまで複雑なのでしょうか? その背景のひとつは、本来のYAMLがJSONとは大きく異なる目的意識で作られているからです。 本稿ではYAML specに従う形でYAMLのコンセプトを解説することを目指します。残念ながら、ここに書かれているYAMLの思想は実際には実用されているとは言い難いですし、これらの背景を理解しても「YAMLは複雑だ」という事実がひっくり返ることはないでしょう。それでも、YAMLの複雑さの源泉を体系的に理解し、YAMLとほどほどの距離感で付き合う助けにはなるのではないかと思います。 この記事ではこういう話をしますYAMLはJSONとは独立に、異なる目的で生まれた野心的な仕様であるアンカーやタグなどの強力な構文は、これらの目的を満たすために
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
GitHub Actions のベストプラクティス
1 フロー 1 ワークフロー 一連のフローがある場合は 1 つのワークフローにまとめる。 トリガーしたイベントの JSON が使える needs での制御がしやすい 全体を追える グラフが表示される ファイルを分割したい ファイルを分割したい理由として以下が挙げられると思います。 行数が増えて読みづらい 処理を共通化したい 複合実行ステップアクション や workflow_run トリガー や Reusable workflow 🆕 を使うことになると思いますが、基本的には一連のフロー制御はメインのファイルに書いてその下を Reusable workflow や複合実行ステップアクションで外部ファイルへ分離するのが良さそう。 workflow_run はログが分断するのでおすすめしません。
Ansibleでリモートのインストールスクリプトの実行をcurlを使わずに記述する - YAMAGUCHI::weblog
TL;DR ansible.builtin.uri でコンテンツを取ってきて ansible.builtin.shell の stdin を使って流し込む サンプル たとえばrustupのインストールは公式ドキュメントでは次のようなスクリプトを使っている rustup.rs curl -sSf https://sh.rustup.rs | sh -s -- -y これをこのまま ansible.builtin.shell に記述して実行すると warning が出ます。たとえばこういう具合にすると - name: Install rustup ansible.builtin.shell: cmd: curl -sSf https://sh.rustup.rs | sh -s -- -y 実行時にこういうふうにwarningがでます。 TASK [common : Run rustup] *
至極の難問YAMLクイズ - くりにっき
前置き 練習問題 問題1 問題2 問題3 問題4 参考文献 おまけ：LT直後のみんなの反応 前置き 社内勉強会のLTで発表したら好評だったので投下 自称YAMLエンジニアのsue445が今まで踏んだ罠をクイズにしました Ruby 3.0.0の Psych で動作確認していますが他言語での挙動は調べていません Psychがlibyamlベースなので他の言語のパーサでもだいたい同じ挙動をすると思うけど 練習問題 Q: 出力されるものは？ yaml = <<YAML a: 1 YAML YAML.load(yaml) #=> ? {"a"=>"1"} {"a"=>1} シンタックスエラー その他 回答 2 YAMLの数字っぽい文字列はその言語の数字の型（Rubyだと Integer ）として解釈されます。 文字列として解釈させたい場合は "1" （ダブルクオーテーション）や '1' （シングルク
Ansible コーディング規約 (の例) — そこはかとなく書くよん。 ドキュメント
Ansible コーディング規約 (の例)¶ edX がgithub上でAnsibleのコーディング規約を公開しています。 https://github.com/edx/configuration/wiki/Ansible-Coding-Conventions このリポジトリは GNU AGPLv3です。翻訳の場合でもおそらく大丈夫だと思いますので、ここで翻訳して公開してみます。 一般¶ YAMLファイル すべてのyamlファイルは2スペースのインデントで、 .yml を拡張子に 付けてください。 変数 jinja変数の形式を使ってください。 $var ではなく {{ var }} です。 jinjaの変数名の前後に空白を入れてください。 {{var}} ではなく {{ var }} です。 環境独自で上書きされる必要がある変数名は全部大文字としてください。 ロール内で完結する変数名は全部
Clang-FormatでObjective-Cのコードを整えたらレビュー捗る - ainameの日記
最近Objective-C書いてるのでClang-Formatというツールを試してみた。 些末なコードレビュー - naoyaのはてなダイアリー にもある通り、コードレビューするときにいちいちソースコードのフォーマットを指摘し続けるのはアンチパターンで、人間以外がやるべき仕事。 PerlならPerltidyというツールがあるけど、Objetive-C（C, C++）にはclang-formatというコマンドがある。暇なので社内で導入出来るように調べた。 ClangFormat — Clang 3.5 documentation 使い方 CLIの場合は以下のように実行する。-iで指定したファイルを上書き、-styleでフォーマットを指定する。 $ clang-format -i -style=Google Hoge.m これだけで既存のコードがフォマッターの設定通りに整えられる。 2014年
EditorConfig
What is EditorConfig? EditorConfig helps maintain consistent coding styles for multiple developers working on the same project across various editors and IDEs. The EditorConfig project consists of a file format for defining coding styles and a collection of text editor plugins that enable editors to read the file format and adhere to defined styles. EditorConfig files are easily readable and they
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Quickstart guide - CircleCI