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
yamlについて思うこと
yaml、どうしてこんなに使われているのだろうか。kubernetesにも責任があるというのはありそうな話だけど、色々考えてみるとそこまで簡単な話でもなさそうな気がする。例えばtravis-CIの設定ファイルがyamlであったりというように、この分野ではyamlは割と広く使われていたんじゃないかという気がする。思い起こせばGoogle AppEngineもapp.yamlに設定を書いていたし、設定にyamlというのは割とよくあることであった、のではないかなあ。 しかしなぜyamlなんだろうか。yamlのフォーマットには問題がたくさんあることが知られているし、自分も全く好きではない。 例えばyamlの問題の一つとして、キーに任意のデータ構造を持ってこれるという話があり、これが一部のプログラミング言語で問題を厄介にしている。またエイリアスがあってデータ構造がツリーにならない（複数の経路から同じ
テクノロジー企業の墓場
(はてなブックマークやTwitterでの対話で詳しい人が色々教えてくれたのでそれに伴って改稿) VMwareがBroadcomに8兆円(!)で買収されるというニュースが報道されている。 Broadcomは通信に必要なチップを寡占している地味なベンダという印象であったので、なんじゃそりゃと思ったら、2005年にプラベート・エクイティが作った会社が買収と売却を繰り返して急成長して、2015年にはBroadcomを5兆円で買収して社名を引き継ぎ、2017年には更にQualcommを買収しようとして米国政府に阻止され、2018年にはCAを買収、2019年にはSymantecを買収と、そういう流れである。 要するに、マーケットを寡占している製品を持つ低成長・斜陽の会社のIPを割安で買って、セールスもマーケティングもR&Dもお金のかかる事は全部辞めて、既存のお客さんからライセンス料をとれる間だけとろう
HerokuのOAuthトークン流出で、やっておくといいことリスト（コメント大歓迎）
2022年4月16日(日本時間)にアナウンスがあった、Heroku/Travis-CIのOAuthトークンの流出および悪用を受けて、ユーザーとしてやっておくといいことをまとめました。 GitHubのOrganizationのオーナー向けと個人向けで分けてあります。 追記: 複数の補足のコメントを頂き、記事にも取り込んでいます。ありがとうございます！ 注意 執筆者はGitHub, Heroku, Travis-CIの専門家ではありません。この記事は誤っている可能性があります。 この記事は現在調査中の問題について書かれています。最新情報は必ず公式サイトをご確認ください。 GitHub Heroku Travis CI インシデントの概要 GitHubがHerokuとTravis-CIのOAuthアプリケーションに発行したトークンが流出・悪用したことで、それらの連携が有効だった多くのOrgani
Security alert: Attack campaign involving stolen OAuth user tokens issued to two third-party integrators
AI & MLLearn about artificial intelligence and machine learning across the GitHub ecosystem and the wider industry. Generative AILearn how to build with generative AI. GitHub CopilotChange how you work with GitHub Copilot. LLMsEverything developers need to know about LLMs. Machine learningMachine learning tips, tricks, and best practices. How AI code generation worksExplore the capabilities and be
Curl プロジェクトが Travis-CI 無料枠を外されそうだとして対応を開始
URL転送ライブラリとそのコマンドラインツールとして有名な Curl プロジェクトの GitHub issues で、travis-ci の無料枠が使えなくなる(travis-ci shuts down the free tier for us)というチケットが上がっています。 有名CIサービスである travis-ci にはオープンソースをサポートする無料枠があり、GitHub 上の多くの OSS プロジェクトで travis-ci が利用されているのもそれによるものです。 curlプロジェクトでも 2013 年から travis-ci で CI を回しており、現在は33個のジョブが走っているそう。今年の3月までは、特別にCPUブーストもしてもらえていたということですが、このブーストは予告なしに止まっていたそう。 travis.ci は今 travis-ci.org から travis-
CircleCI や TravisCI などの CI サービスの無料枠を食いつぶす暗号通貨採掘者
CIサービス(Continuous Integration = 継続的インテグレーション)の LayerCI の CEO がブログで指摘したのが、LayerCI やその競合である GitLab, GitHub Actions, TravisCI, CircleCI, Wrecker などのサービスの無料枠を悪用した暗号通貨マイナー(miner = 採掘者)の実例です。 CIサービスの無料枠 CIサービスでは、GitHub や BitBucket などのソースコード管理サービスでコードの変更がある度に、自動的にテストセットを実施し、ソフトウェアが壊れていないかを確認してくれます。CIサービスはこれらのテストを実施するためのコンピューター資源を大量に確保・実行しています。 多数のプロジェクトを持つ企業は毎月の使用料を払ってこれらCIサービスを利用しますが、普及宣伝のために個人開発者やスタートア
Cargo.toml を壊れたままにしない
Cargo.toml を壊れたままにしない Rust で Cargo.toml により依存パッケージのバージョン指定をしますが、これが壊れている場合が見受けられます。 このような問題の解説や、気付いて直すための方法についての話です。 この記事は Rust Advent Calendar 2020 の14日目の記事です。 前日になっても枠が空いていたので、最近思うところを急遽突っ込むことにしました。 前日の記事は『Dhallの型定義からRustの型を自動生成するマクロ』でした。 TL;DR もう少し詳しくは まとめ を参照のこと。 依存バージョンを指定するときは、マイナーバージョンやパッチバージョンまで含めて最新のものを指定しましょう。 cargo +nightly update -Z minimal-versions で、制約を満たす最小バージョンへの依存を使った Cargo.lock を
今までありがとうTravis CI、さよならTravis CI - xuwei-k's blog
しっかり調査してないですが、こういったCIサービスがほぼ存在しない時期にほぼほぼ最初に登場して、一時期明らかにデファクトスタンダードだったと思うので、昔からOSS活動している人ほど、とても多く利用してお世話になっていたと思うので、そういう人であればあるほど、この状況は、怒りではなく、悲しいというか残念というか、辛いと思うんですよね・・・。 今までありがとう・・・。 長年Travis CI使ってきたので、GitHub Actionsによって潰される(のかどうなるのかわからないけど)、の可愛そう、という気持ちが若干あるけど、とはいえ、こういうのよくある話な気はするな…— Kenji Yoshida (@xuwei_k) 2020年10月7日 買収されて方針変わったのかなと感じるところもありますし、OSSプロジェクトが無料で使っていても会社としては辛いのではという気もするので今までの感謝の気持ち
dotfilesのためのAcceptance Testをgossで宣言的に記述する - Steel Dragon 14106
dotfilesのためのAcceptance Testをgossで宣言的に記述する By raimon, 2020-02-03(月), in category Git dotfilesで保証したいテスト ソフトウェアエンジニアで、自身のHOMEディレクトリ以下に設置するファイル群（いわゆるdotfiles）をGitで管理している人はそこそこ居ると思う。 ポピュラーなやり方は、GitHubに代表されるGitリポジトリをホストできるサービスで管理し、手元に git clone して持ってきて setup.sh や install.sh のようなスクリプトを実行し、Git管理下のファイル群をHOMEディレクトリにコピーしたりシンボリックリンクを作成する流れである。 長くGitで管理していると、時々ふっと改善したい意欲が湧き上がってきて、かなりの量を書き直した結果、インストールスクリプトの結果が壊
CIマニアから見た各種CIツールの使い所 - くりにっき
社内外でちょいちょい聞かれるのでメモ。 前置き GitHubを使ってる場合 ライブラリを作ってる場合 Travis CIを選択する理由 2020/4/21追記 Travis CIを選択しない理由 アプリを作ってる場合 CircleCIとWerckerの共通点 CircleCIとWerckerの機能差異 GitLabを使ってる場合 GitLab CIの優位点 Jenkinsなどを使った方がいい場合 追記：2018/12/8 前置き 100%自分の主観なので偏ってます SaaSかオンプレならSaaS派。（自分でサーバの面倒身たくない） 自分が使ったことがないものは紹介していません 今回紹介してるTravis CI, CircleCI, Wercker, GitLab CI, Jenkinsに関しては仕事や趣味で各3〜4年くらいは使ってるはず GitHubを使ってる場合 ライブラリを作ってる場合
Travis CIのcron jobsを使ってGitHubに定期的にcommitする方法 - hnwの日記
みなさん、Travis CI使ってますか？Trais CIはクラウドCIサービスの1つで、GitHub上で公開しているOSSを自動テストする目的であれば定番中の定番といっていいサービスです。 ところで、さいきん私の公開しているプロジェクト「hnw/wsoui」で以下のことを実現したいと考えました。 ネット上のデータを加工してGoの連想配列の形で提供したい 変換スクリプトは作成済み 自動更新したい 情報ソースは不定期に更新される そこそこ最新のデータを反映していてほしい これを実現する方法は何種類か思いつきますが、今回Travis CI のcron jobsを使って1週間に1回、更新があったときだけgit commitするような仕組みを作りましたので、これを紹介します。 Travis CI のcron jobs Travis CIでは、gitリポジトリに新たなcommitがpushされるたび
Markdown lint toolでMarkdownファイルの構文のLintをチェック - Steel Dragon 14106
$ bundle exec mdl --help Usage: mdl [options] [FILE.md|DIR ...] -c, --config FILE The configuration file to use -g, --git-recurse Only process files known to git when given a directory -i, --[no-]ignore-front-matter Ignore YAML front matter -l, --list-rules Don't process any files, just list enabled rules -r, --rules RULE1,RULE2 Only process these rules -u, --rulesets RULESET1,RULESET2 Specify add
Travis CI Documentation
This documentation site is Open Source. The README in our Git repository explains how to contribute. Travis CI relies on Open Source licensing information. Please note that, due to the upcoming Docker Rate Limit announcement, users will be required to add their own authentication information to their build settings or build config as documented below. Travis CI builds can run and build Docker imag
Go でツール書くときの Makefile 晒す - Qiita
Go でツール書くときはタスクランナーとして make を使っています。ビルドだけじゃなくて、テストや配布用パッケージ作成も一括して make でやっています。 今回は整理も兼ねて、自分が普段どういう Makefile を使っているのか解剖していきます。 なぜ make を使うのか ビルドフラグ覚えるのが面倒だから、make は (Windows を除く) 大半のプラットフォームに入っていて使いやすいからというのが理由です。script/build みたいにシェルスクリプトを複数用意するのでもまあ良いと思いますが…。大半の Go プロジェクトは Makefile 置いてありますね。 make を使った開発フロー 基本的には、リポジトリを git clone / go get -d した後に以下のコマンドを打てばアプリケーションをインストールできるようにしています。 $ cd $GOPATH
インフラエンジニアのいない会社で働いて 1 年半 - Diary
インフラエンジニアのいない会社で働いて 1 年半 が経った。 iOS で動く POS レジアプリとその管理インターフェイスの Web アプリケーションを作ってます。 iOS 側のことはほとんど分からなくて、データ同期用 API と Web アプリをずっと作っている。 ところで、 「NoOps」の時代がこない理由という記事が前にあったのですが、この点ぼくが働いている会社は NoOps です。アプリケーションは Heroku に乗っていて、 RDBMS が Amazon RDS で一部分析系に Google BigQuery を使っていること以外は全て Heroku 系の何かで動いています。 CI は Travis と circleCI を使っていて、 circleCI については来年初頭にも利用をやめて Travis に一本化する予定、というかんじ。 本当に自分達でなにもサーバーを管理してい
AWS CodeBuild をちょっと触ってみた - Diary
AWS CodeBuild をちょっと触ってみた フルマネージドのビルドサービス という触れ込みで、実際まあその通りなんだけど、これはあくまでもビルドツールであって CI ツールではない。出来ることはビルドだけ。 なので Amazon Travis 的なサービスではない。 AWS CodePipeline や Lambda や API Gateway などと組合せることで一気通貫の CI 環境を構築することはもちろん可能だが、大抵の場合において Travis に金を払ったほうがいいと思う。 Jenkins おじさんならぬ AWS CodePipeline が発生してしまう。 ビルドタスクが大量にあり Travis なり Jenkins なりのレーンが頻繁に逼迫してる会社ならばこれらサービスを使ってやっていくコストをペイできることでしょう。 一方で個人が Github の Private リ
複数バージョンのPython向けにCI環境を構築してテストする - Qiita
Python Advent Calendar25日目を担当します@giginetです。最終日なので遅れないように何とか書き上げました。 先日、Django向けに簡単なプラグインを開発しました。 そこで、実装したプラグインをPython2と3の違いを吸収して複数環境でテストするようにCI環境を構築したところ、ハマりどころが多かったため、この機会にまとめてみます。 この記事ではTravis CIを使って、複数のPythonバージョンにまたがるテストを実行して、カバレッジを計測する方法をご紹介します。 モジュールを実装する まず、テストしたい簡単なモジュールを実装しましょう。今回はcalculatorモジュールにcalculator.pyを置き、Calculatorクラスを実装しました。 今回は全てのコードをPython3で実装することを想定しています。
Swift CLI環境におけるTravis CIを利用した継続的Lint - Steel Dragon 14106
Swift CLI環境におけるTravis CIを利用した継続的Lint By raimon, 2016-05-05(木), in category Xcode Xcodeに付属する swift コマンドを使い、『詳解 Swift 改訂版』のサンプルコードを写経したり、書き換えて動作を確認したりするGitリポジトリを作った。 せっかくGitHubにホスティングしているので、学習しながら継続的にSwiftLintで好ましくない書き方を自動検知できると良いのではないかと考えた。 成果物 raimon49/swift-definitive-guide-2nd-edition-study 最低限で必要になるのは次のファイルである。 インストールスクリプトの準備 Travis CIのビルド環境へSwiftLintを導入する最速の手段は、リリース済みpkgファイルを取得し、OS Xの installe
変更したファイルにrubocopやjscsを実行して pull requestに自動でコメントする
tl;dr 変更したファイルにrubocopやjscsを実行して、pull requestに自動でコメントさせる方法。 コマンドをパイプでつないで、CIからsaddlerコマンドで書き込みする。 デモリポジトリに rubocop, travis ci, jscs, travis ci エラーになるpull requestしてみてね! saddlerの実行結果イメージ 一番目がjscs, 二番目がrubocop。 流れ diffのあるファイル名を取り出す $ git diff --name-only origin/master README.md bin/run-tests.sh lib/example/travis_ci.rb こんなdiffにrubocop や jscsを実行したい。 diffのあるファイル名を取り出す。 lint実行したいファイルだけに絞り込む $ git diff -
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
