Codecov is now open source - Codecov
Authors Note: Hey, we messed up in this post by referring to BUSL-1.1 as Open Source. We’re sorry, we are leaving this post as-is to keep the record clear and we’ve followed up in a new post. Since the beginning, the open source community has been a strong partner in Codecov’s growth and success. That’s why we always offered Codecov for free to use on any open source project. And if we’re being to
BuildJetを使ってamd64とarm64に対応したコンテナイメージを今までの8倍速く作る - 風に吹かれても
三行まとめ BuildJet が提供するArmマシンを用いてArmで動くイメージを作成する Docker Buildx を用いると複数のイメージに同じタグを貼ることができる Actionsのx86_64マシンでamd64で動くイメージを、BuildJetのArmマシンでarm64で動くイメージをそれぞれ作成してくっつけた 三行まとめ はじめに BuildJetとは 方法 BuildJetに登録する BuildJetを有効にする runs-onにBuildJetのランナーを指定する 複数のイメージを束ねるマニフェストを作る めでたしめでたし 実際に使ってみる 速度比較 まとめ はじめに Apple Silicon搭載マシンの登場、Raspberry Piの普及などArmが身近になってきた人も多いのではないでしょうか。 Raspberry Pi上で動くKubernetesなどを運用する際にはa
Docker is deleting Open Source organisations - what you need to know
Coming up with a title that explains the full story here was difficult, so I'm going to try to explain quickly. Yesterday, Docker sent an email to any Docker Hub user who had created an "organisation", telling them their account will be deleted including all images, if they do not upgrade to a paid team plan. The email contained a link to a tersely written PDF (since, silently edited) which was mi
Dockerに関するキャッシュたち
はじめに Dockerを用いた開発では、適切にキャッシュを用いることで高速にビルド・開発できます。そのための知見は様々な記事で共有されており、ありがたい限りです。 しかし、「Dockerのキャッシュ」と言っても開発時とCI・CDでは行うことが違います。 この記事ではDockerを用いた開発における、各段階のキャッシュ機能を確認したいと思います。 主に「Dockerのキャッシュ」というと以下の4つに分類できると思いますので、それぞれについて解説していきます。 Dockerのレイヤーキャッシュを活かす a. COPY・ADDの順番 b. dockerignoreの設定 c. マルチステージビルド buildkitによるキャッシュ a. --mount=type=cache CI・CDにおいてのキャッシュ a. 前回のビルドキャッシュを持ち越して使う リモートキャッシュ a. 開発者が初めてビル
GitHub Actions のベストプラクティス
1 フロー 1 ワークフロー 一連のフローがある場合は 1 つのワークフローにまとめる。 トリガーしたイベントの JSON が使える needs での制御がしやすい 全体を追える グラフが表示される ファイルを分割したい ファイルを分割したい理由として以下が挙げられると思います。 行数が増えて読みづらい 処理を共通化したい 複合実行ステップアクション や workflow_run トリガー や Reusable workflow 🆕 を使うことになると思いますが、基本的には一連のフロー制御はメインのファイルに書いてその下を Reusable workflow や複合実行ステップアクションで外部ファイルへ分離するのが良さそう。 workflow_run はログが分断するのでおすすめしません。
GitHub Actions上のRustアプリのDockerイメージビルドを高速化する - blog.endflow.net
Rust + Docker + GitHub Actions = めちゃ遅い 以前、GitHub Actions 上の Rust ビルドを高速化する記事を書いたけど、 今回は Kubernetes 環境にスムーズに移行できるよう Docker イメージ化するという要件も加わったことで、改めて試行錯誤する必要が出てきた。 それぞれに対するビルド速度の最適化は存在しているものの、３つ (Rust, Docker, GitHub Actions) すべてを満たすとなるとコピペで終わるほど情報がまとまってないし、見つけた Tips もちょっと古かったり、これというものは見つけられなかった。 公式ドキュメントを見ると正当進化していて新しいオプションが生えていたりしたので、賞味期限は短そうだけど、自分の試行錯誤の結果を残しておこうと思う。 成果としては 12 分 22 秒かかっていた Rust アプリ
GitHub Actions向け自作アクションの作り方｜Tably
こんにちは。Tably よういちろう（@yoichiro）です。 皆さんは普段GitHubをお使いでしょうか？お使いの方は、GitHub Actionsを使ってCI/CDしていますでしょうか？ GitHub Actionsを使うことで、Pull Requestの作成や更新、あるブランチへのマージといったタイミングで、コードのフォーマットを整えたり、テストを走らせたり、本番環境にデプロイしたり、一連の作業が終わったことをチャットに通知したり・・・といったことを自動的に行うことができます。GitHubにはGitHub Marketplaceというアクションが公開されているマーケットプレースがあります。やりたいことがあった時に、一般的なものであればそこで見つけることができるでしょう。 ものすごい数のアクションがMarketplaceにて公開されていますが、たまたま僕が行いたかった動作をしてくれる
Dockerfile をベースイメージの更新に自動で追従させる - 詩と創作・思索のひろば
前回のエントリで作った Docker イメージ motemen/datastore-emulator は、google/cloud-sdk をベースにしているが、このベースイメージがけっこうな頻度で更新される。とうぜん自分はその追従に手を煩わせる気はなくて、全部自動でやってほしい。 やりたかったこと google/cloud-sdk:x.y.z がリリースされたら、 リポジトリ中の ./Dockerfile と ./alpine/Dockerfile の FROM を google/cloud-sdk:x.y.z(-alpine) に更新し、 x.y.z タグを打って git push することで、 Docker Hub に x.y.z(-alpine) タグとしてリリースする これを自動かつ無料で実現したい。 採用しなかった案: 自分でなんか作る はじめは適当な GitHub Actio
Docker Hubの不正アクセスについてまとめてみた - piyolog
2019年4月27日、Dockerはコンテナ共有サービス「Docker Hub」が不正アクセスを受け約19万件のアカウントに影響が及んだとして情報漏えいの可能性について発表しました。ここでは関連する情報をまとめます。 公式リリース success.docker.com 被害の状況 Docker Hubのデータベースが不正アクセスを受けた。 不正アクセスにより一部のユーザー情報が盗まれた恐れがある。 影響を受けたのは約19万件のアカウント。全ユーザー数の約5%未満。 Dockerは不正アクセスの時間は短時間と説明。 2019年4月25日にDockerがDocker Hubデータベースへの不正アクセスを把握。 この侵害によるDockerの公式イメージへの影響はない。 不正アクセスの手口については明らかにされていない。 メール届いた場合は影響を受けた恐れ Dockerから連絡メールが届いた場合は
Features • GitHub Actions · GitHub
error-pages GET / ✓ should respond with page list Accept: text/html GET /403 ✓ should respond with 403 GET /404 ✓ should respond with 404 GET /500 ✓ should respond with 500 Accept: application/json GET /403 ✓ should respond with 403 GET /404 ✓ should respond with 404 GET /500 ✓ should respond with 500 Accept: text/plain GET /403 ✓ should respond with 403 GET /404 ✓ should respond with 404 GET /500
2018年なぜ私達はコンテナ/Dockerを使うのか | iret.media
2017年にもうコンテナの未来・一つのカタチはもう確定したと言え、今更感があるものの、改めてDockerとコンテナについて。 今更こんなことを書くのは、情報が溢れてくる今こそ、正しく理解し、正しい順序で学習することが重要だと切に思うから。 内容についてのお断り How Toはかきません あくまでも2018年時点の私見 目新しい情報はない、2016年頃に書けたレベル Dockerをこう使えとか、こうするのがいいとかの話ではなく、コンテナとDockerに関して大きな視点で現時点で私の考えを書きます。また、私自身はかなりのコンテナ推進派です。 Dockerをよくわかっている人には意味のない記事となります。 コンテナ(Docker)のメリット 何故コンテナがいいのか、コンテナをある程度の学習コストを払ってでもやる理由 コンテナとDocker コンテナ技術はDockerが生まれる前から存在する技術で
他言語から来た人がGoを使い始めてすぐハマったこととその答え - Qiita
環境構築するまでに知りたかったこと Golangの最新バージョンは？ 1.16.6 (2020/07/12リリース) Goのインストール方法は? macOS の場合は brew で OK この場合、goのsdkは /usr/local/Cellar/go/<バージョン>/libexec にインストールされます。 IntelliJ IDEA や GoLand にような IDE に「GOROOT」というものの指定を求められたら、このパスを使います。 brew で入らないバージョンの go が必要だったり、いくつかのバージョンを併用したい場合は $ go get golang.org/dl/go1.14.4 $ go1.14.4 download # 1.xx.0 の場合 $ go get golang.org/dl/go1.15 $ go1.15 download # 上記でgo getしたg
【翻訳版】Docker, Inc is Dead - comix
What's this? Docker, Inc is Dead の翻訳記事です。 ご本人の許可は取っていますが、僕が英語ペラペラではないため、読み辛いのはもちろん、一生懸命訳してはいますが誤訳・ミスリードなどあるかもしれません。 ですので、100%正確な内容を把握したい方は原文をお読みください。また、ここ間違ってるよ！ニュアンスが違うんじゃない？などありましたらお気軽に（優しく）コメントいただけると幸いです。 Docker, Inc is Dead / Docker社は死んだ Dockerにとって、2017年は非常に辛い1年だったと言っても過言ではありません。Uberを除いて、より活用され、賞賛され、十分に資金提供を受けたシリコンバレーのスタートアップの中で、Dockerが2017年に行ったような悪手を打ったスタートアップは思い浮かびません。人々は2017年を、ソフトウェアの偉大な一部分
GitHubの docker/docker は moby/moby になりました。 | DevelopersIO
ども、大瀧です。 昨日から開催されているDockercon 17では、Docker関連の多くの発表がありました。 その中のひとつにMobyプロジェクトがあり、プロジェクト発足に合わせてGitHubのdocker/dockerリポジトリがmoby/mobyリポジトリに移動しました。今後Docker CE(Community Edition)のソースやIssueなどを見るときは、こちらのリポジトリにアクセスしましょう。 このブログでお伝えしたいことは以上なのですが、「Mobyってなんだよ?!Dockerが名称変更したの?」と言われそうなので、ちょっとだけ解説します。経緯についての一次情報は、以下をご覧ください。 Transitioning to Moby by shykes · Pull Request #32691 · moby/moby ほどなくちゃんとした説明がDocker社のブログなど
Go でツール書くときの Makefile 晒す - Qiita
Go でツール書くときはタスクランナーとして make を使っています。ビルドだけじゃなくて、テストや配布用パッケージ作成も一括して make でやっています。 今回は整理も兼ねて、自分が普段どういう Makefile を使っているのか解剖していきます。 なぜ make を使うのか ビルドフラグ覚えるのが面倒だから、make は (Windows を除く) 大半のプラットフォームに入っていて使いやすいからというのが理由です。script/build みたいにシェルスクリプトを複数用意するのでもまあ良いと思いますが…。大半の Go プロジェクトは Makefile 置いてありますね。 make を使った開発フロー 基本的には、リポジトリを git clone / go get -d した後に以下のコマンドを打てばアプリケーションをインストールできるようにしています。 $ cd $GOPATH
Run Kubernetes on a Mac with Kube Solo
Explore Azure Get to know Azure Discover secure, future-ready cloud solutions—on-premises, hybrid, multicloud, or at the edge Global infrastructure Learn about sustainable, trusted cloud infrastructure with more regions than any other provider Cloud economics Build your business case for the cloud with key financial and technical guidance from Azure Customer enablement Plan a clear path forward fo
Jenkins User Conference 東京 2015
DOO-003_Jenkins 作者が語る、Docker コンテナによる継続的デリバリのオススメと新機能のご紹介
Plagger 入門 in 2014
この記事は Perl Advent Calendar 2014 の 12日目の記事です。いいですか、2014 ですよ。あなたは間違えて2008年の Advent Calender を開いてしまったわけではないので安心してください。 11日目の記事は hisaichi5518 さんの Data::DumperとB::Deparseを合わせて使ってみる。 でした。 Plagger とは、（Rebuild.fm の）miyagawa さんが中心となって開発されていた Perl 製のフィードアグリゲータで、プラグインを組み合わせることで RSS フィードなど様々なデータを任意の形式に変換して出力させることができるものです。雑に言うと ifttt のようなもの（のはず）です。 今は代替となるような Web サービスがあったり、そもそも RSS フィードや Web hooks がきちんと用意されている
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub
The Walt Disney Company
