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
iOSアプリにも継続的インテグレーション環境を こんにちは！今日からMacDownでブログを書いています。荒川です。 モダンなWeb開発では馴染み深くなってきた、CI（継続的インテグレーション）環境を iOS 開発でも弊社では積極的に取り入れています。社内での共有も兼ねて、今回は簡単にまとめます。 「継続的インテグレーション」と聞くととても難しそうで、設定も大変そうです。ですので、最低限コピペで作れる程度の環境構築方法を紹介します。 iOS 開発での CI とは何かを詳しく知りたい方は、弊社諏訪の記事 iOSアプリ開発でCI／継続的デリバリ環境を始めるための4種の神器 を参考にしてください。 今回構築する環境は、以下に該当する方に最適です。 gitを使って iOS 開発を行っている。 チーム内でチャットツールを使っていて、そのAPIが公開されている。 テストコードを書いている。または、その
![[iOS 8] 15分で作れる CI 環境構築 | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/b77d33dc9028edad7cf9c2e97b877fb489d569fc/height=288;version=1;width=512/https%3A%2F%2Fsiteproxy.ruqli.workers.dev%3A443%2Fhttps%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2014%2F11%2Ftravis.png)
Jenkinsのジョブ結果をプルリクエストに表示するときはGitHub pull request builder pluginを使ってますが、単体のジョブでしか利用できなかったので、複数ジョブ（ビルドパイプライン構成）のときに結果を表示する方法をまとめておきます。 ビルドパイプラインの構成 今回のビルドパイプラインはこんな感じを想定しています。 プルリクエストへの更新やコメントをトリガーにジョブが起動し、単体テスト、回帰テストを実行します。 あわせて、実行中、失敗、成功の状態がプルリクエストに表示されます。 成功したらプルリクエストに ╭( ･ㅂ･)و ̑̑ ｸﾞｯ ! って出ます。ｸﾞｯ ! って。 これを満たす以下のジョブをつくっていきます。 ジョブの結果をプルリクエストに表示する 複数のジョブをビルドパイプラインとして実行する GitHub pull request builder
This webpage was generated by the domain owner using Sedo Domain Parking. Disclaimer: Sedo maintains no relationship with third party advertisers. Reference to any specific service or trade mark is not controlled by Sedo nor does it constitute or imply its association, endorsement or recommendation.
Gitを日常の開発に使っていても、Gitがどのように動作しているのかや、ブランチやコミットがどのような概念なのかをはっきいりと理解していない人は少なくないでしょう。今回、GitHubのJohn Britton氏がイベントの為に来日し、下北沢オープンソースカフェにてGitについての非常に細かい内容についてのセッションを行ってくれました。 動画 90分ほどのセッションが高画質で録画されています。全編英語のセッションとなっていますが画面も見やすいのでご覧になってみてください。Gitのリポジトリがどういった情報を操作しているのかなどをさまざまなコマンドの実行結果と共に解説を加えるわかりやすい内容です。 大まかな話題 Gitのリポジトリの基本概念 ツリーオブジェクト・オブジェクト ワーキングコピー、ステージング、ヒストリの違い ブランチの動き セッション中のハイライトをいくつかをツイートからご紹介し
常連プログラマがほぼ Rubyist しかいないP4Dなのですが、なぜかPHPカンファレンスで枠をいただいたとのことで、デザイナーとGitについて話し合ってみようという企画に参加してきました。 「生煮えぷるり」をプログラマとデザイナーの間で行ったり来たりさせる話 Pull Request 4 Designers - GitHubを使ったプログラマとデザイナーのイテレーティブな開発フロー// Speaker Deck GitHubを使った、実際のプログラマとデザイナーの協業の様子を見てもらおうということで、私がお手伝いさせていただいている、[https://forkwell.com:title=Forkwell] と [https://jobs.forkwell.com:title=Forkwell Jobs] での開発の様子を例にお話させていただきました。 補足とか 「生煮えぷるり」という
http://boxen.github.com/ https://github.com/boxen/boxen https://github.com/boxen/our-boxen スゴイスゴイと言われていて誰も使っていないBoxenだけど、昨日の朝コードを読んでみた。折角なので、boxenコマンドを実行すると何が起こるのかというのを、Rubyのメソッド単位のコールグラフという形で簡単に説明する。 処理の流れ 1. レポジトリをgit-pullで更新 2. 環境変数や前回実行時に保存しておいたJSONから設定を読み込み 3. 前処理 4. コマンドライン引数に応じて 4-A. puppet-applyを実行 → 後処理 4-B. その他便利コマンドを実行 → 終了 Puppetの扱い librarian-puppetという仕組みが利用されていて、Puppetfile(=Puppet版Gem
世界一簡単なGithub入門（githubは無料で使用する場合、全てのファイルが公開されていることにご注意ください） ややこしいコマンドを全スルーして個人用バックアップとして使ってみる 2013.01.26 LDD13 LT 【概要】 次々と新しい技術やサービスが公開され、いろいろ挑戦してみたい・・・とは思うのですが、それが複雑なものだったり高機能であったりすると、どうしても最初のハードルが高く、なかなか踏み出せないと感じます。 そんな時、私の場合は、とりあえず、できるだけ簡単なマニュアルを探してきて、良く分からないところは全部無視して無理やり使ってみることにしています。訳が分からないままでも、使っていることで、ちょっとずつイメージが湧いてきて、画面が見慣れたものになってきます。そして、それから改めて入門書を読み始めます。そうすることで、最初のハードルが、少しは下がるのではと考えています。
はじめに¶ 巷に溢れているHaskell本はいきなりのIOを避けているものが多いですよね。こ れらの本を読んでわかった気になっても、実際に日々のタスクに使おうとした 場合に結構ハマることが多いんですよね。 「習うより慣れろ」みたいなスタイルでHaskellの学習をするとどういう学習曲 線をたどることになるんだろうか? phpのように動けばいいや(偏見?)というス タンスでHaskellのコードを書くことは可能なんだろうか? と疑問に思ったので、よくあるスクリプト言語の入門書(IOから入る系)のよう な話題を取り扱ってみようかなと。 Sphinxという良い感じに文章をかけるツー ルと、書いた文章をGitHub Pagesで手軽に公開できるような環境の存在も、こ の試みを後押ししました。というか書いていて楽しいので、みなさんもSphinx つかうとハッピーになれると思います。 フィードバックな
アッド & コミット 変更されたファイルを選択します。 git add <filename> git add * を実行するとIndexに追加されます。 これは基本的な作業の一つです。 変更を実際に適用するには git commit -m "Commit message" を実行します。 変更がHEADに入りましたが、 リモートリポジトリには未だ入っていません。 変更のプッシュ この時点で、変更がローカルリポジトリのHEADに適用されました。この変更をリモートリポジトリに適用するには git push origin master を実行し、masterの代わりに適用のブランチ名を入れます。 もし既存リポジトリをクローンせずに使用した場合 git remote add origin <server> を実行すると、リモートリポジトリを登録する事が可能です。 これで変更を特定なリモートリポジト
JavaScript Garden はJavaScriptというプログラム言語の一番奇妙な部分についてのドキュメント集です。 このドキュメントはJavaScriptという言語に慣れていないプログラマーがこの言語について深く知ろうとする際に遭遇する、良くある間違い・小さなバグ・パフォーマンスの問題・悪い習慣などを避ける為のアドバイスを与えます。 JavaScript GardenはJavaScriptを教える事を目的にしていません。このガイドの項目を理解する為には、この言語に対する前提知識がある事を推奨します。この言語の基礎部分についてはMozilla Developer Networkのガイド がオススメです。 著者 このガイドは愛すべきStack Overflowの2人のユーザーIvo Wetzel (執筆)とZhang Yi Jiang (デザイン)によって作られました。 貢献者 貢献
みなさん、Git使ってますか？僕はまだメインのVCSがSubversionなのもあって、なかなか慣れません。せっかくGitを使っているのに、ちょっと不便なSubversionくらいの位置づけです。でも、同じような理解度の人って多いんじゃないでしょうか。 一方で、最近はGitHub管理のオープンソースプロジェクトが増えてきました。バグレポートを送るにしてもpull request*1が前提のような空気があり、Git初心者には少し敷居が高い印象があります。 そんな僕も先日初pull requestをしてみたんですが、色々な失敗の積み重ねで残念なpull requestになってしまいました。その反省を元に、本稿ではpull requestする際のベストプラクティスを紹介します。これは「Git Workflow」をベースにコマンド例などを加筆したものです。 概要 pull requestする際は、
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
