状況 gitlabのリポジトリにコミットされたらテストを実行して欲しいが、その前に別のリポジトリにあるソースをチェックアウトして準備する必要がある（モックを返すプロセスを起動しないといけない・・・） ちゃんとプッシュされたブランチに対してテストして欲しい 結論 jenkinsのgitlab pluginではなく、git pluginを使い、pushされたブランチ名を取得する Parameterized Trigger Pluginを使って、ビルドに変数を渡せるようにする hookを受け、ブランチ名を下流プロジェクトに流すジョブを作成する（間に別のリポジトリに対するジョブが挟まるため） 仕事を振り分けるジョブを作成する
PWA-Editor(仮) デザインとかは適当なんだけど、コンセプト的にどこまで実装可能かの検証を一通り終えた。頑張れば本格的なものが作れそう、という手応えがある。 IndexedDB バックエンドに fs 動かして ismorphic-git を動かしている。 UIは全然足りないが、 ポテンシャル的には GitHub に push できることも検証済み。ServiceWorker でオフラインで動くようになっている。 デプロイ先は https://nervous-kilby-73c9b0.netlify.com/ 開発中のものなので、予告なく互換が壊れることがある。 動機 Chromebook 買ったんだけど、やはり開発機として使うには厳しい気持ちがあった。主にまっとうなエディタがないのが辛い。cloud9 とか試したけど、辛かった。 フロントエンドのツール周りはJSで完結して PWA
今回の課題 こんにちは植木和樹です。7月にserverspecを使ったChefの自動テストのエントリを書きました。 【AWS】JenkinsとserverspecでChefのテストを自動化する このエントリは初めてJenkinsを触った時に書いたので、いろいろと流儀がわかっていませんでした。その後弊社にJenkinsマイスターの渡辺修司さんが入社したということで、Jenkinsの設定について見てもらいました。その時に次の6点を見直すよう指摘がありました。 ジョブは意味ある単位で1つにまとめるべし ジョブで実行するシェルスクリプトもgitから取得すべし EC2の起動に失敗したら後続処理を停止させるべし serverspecの実行結果はJUnit（XML）形式で出力すべし 実行結果のXMLをJenkinsで読み込んで統計グラフを出力すべし 定時実行でなくgit push hookを入れるべし
モバイルアプリエンジニアの山下です。 チームで開発を進める上でちょっとした"決まりごと"が存在すると思います。 例えば、LCLの開発チームには以下の"決まりごと"が存在します。 コミットメッセージの先頭にはYouTrackのIssue番号を付ける RuboCopで設定したコーディングスタイルになるべく従う masterへ直接PUSHはしない これらを全員が心がけることで運用効率や品質を保つようにしていまが、とはいえコミットする度にIssue番号を入力したり、RuboCopのコマンドを打ったりするのは非常に面倒です。 そこで今回は「git hooks」を利用してコミットやプッシュのタイミングで自動的に実行されるようにしました。 git hooksとは コミットやプッシュなどのgit操作をトリガーにしてスクリプトを実行する機能です。 .gitディレクトリ内にhooksという名前のディレクトリで
gitのコミットメッセージにissueの番号が書いてあると、後からこの変更なんだっけ...？という時に追いやすくて便利な気がしている。 なんだけどいつも書くの忘れるので自動で入れるようにしてみた。 Qiitaでやり方を書いてくれている方がいたので参考にさせていただきました。 qiita.com 上記の記事からの変更点 ブランチ名はいつも add-hogehoge_#{issue番号} みたいな感じでつくっているのでそれに合わせて書き換えた。 git commitする時にissue番号を自動で入力するgit hooks "末尾の数字" を切り出すようにしても良かったが、ブランチ名にissue番号以外の数字を入れることはあまりないので数字以外の文字を削除する正規表現にしている。 これを作業リポジトリの .git/hooks/prepare-commit-msg に保存して実行権限をつけてあげれ
ゴール Gitlabへpushされたブランチによって、Jenkinsでビルドする内容を切り分けること。 developブランチへのpush → develop-build用のJOBを起動する masterブランチへのpush → master-build用のJOBを起動する イメージ こんな感じ。 GitlabのWebHook └─> JenkinsのtriggerJOB ├─> develop-build用JOB └─> release-build用JOB Jenkinsで分岐を実現するだけなのでそんなにハマるとは思ってなかったけど、その考えは甘かった。。 結論だけ知りたい人はいきなり「実現する方法まとめ」へ。 試したこと１ ParameterizedTriggerPluginを使う https://wiki.jenkins-ci.org/display/JENKINS/Paramete
7. Gitにおけるコミットの具体例 cat-file でGitオブジェクトの中身を表示 % git rev-parse HEAD^ 6f73c5b7753ffca739ae24f489617c7652e2728e % git cat-file -p 6f73c5b7753ffca739ae24f489617c7652e2728e tree 48df9351f27ba6927521a99575d85cf9805360c3 parent 9db8e21517181dae8cc9dda22f63db818d13edde author Katsuyuki TATEISHI <kt@wheel.jp> 1437109176 +0900 committer Katsuyuki TATEISHI <kt@wheel.jp> 1437109176 +0900 Add a beautiful featur
はじめに 以前は「貧者の GitHub Enerprise」などと言われることもあった GitLab ですが、「GITLABはブランチ毎に書き込み権限を制限できるという点においてGitHubよりも圧倒的に優れている」という意見も見られるなど、機能面、安定面ともに着実に進歩しています。 そのインストールの難しさが話題に挙がることもありましたが、公式インストールドキュメント はとてもよく書かれていますし、Chef の Cookbook なども多数存在します。個人的に Chef より Ansible が使い易かったため、CentOS 用の playbook も書きました。 以上のような状況から、GitLab は何らかの理由で GitHub や GitHub Enterprise を利用できない環境においても、Git および Pull Request (Merge Request) による開発フロ
こんにちは！テニスはじめました、小山です。開発部門でウエディンググループのリーダーをやっています。 今回は私が考えた新しいGitのブランチモデル「GitFeatureFlow」についてお伝えしたいと思います。 GitFeatureFlowとは Gitを使った開発をより快適にするため、GitFlow,GitHubFlow,GitLabFlowではない、新しいGitのブランチモデル「GitFeatureFlow」を考えました。 Gitを利用して開発を行う場合、Gitのブランチモデルをどうすべきか悩むことが多いかと思います。私自身もこの悩みに直面しました。既存のブランチモデルでは問題が解決できなかったので、GitFeatureFlowという新しいブランチモデルを考え、ウェディンググループに導入。今では快適にGit開発を行っています。 GitFeatureFlowで使う主なブランチはこの3つです。
(訳注：2015/10/31、いただいた翻訳フィードバックを元に記事を修正いたしました。) (訳注：2015/11/1、いただいた翻訳フィードバックを元に記事を再修正いたしました。) 訳： プロジェクトが長引くほど、私のGitのコミットメッセージは情報が薄くなっていく。 イントロダクション | 7つのルール | ヒント イントロダクション：なぜ良いコミットメッセージを書くことが重要か Gitのリボジトリのログをランダムに閲覧すると、ひどいコミットメッセージを目にすることがあります。例として、私が昔書いたSpringにコミットした これらのgem を見てみましょう。 $ git log --oneline -5 --author cbeams --before "Fri Mar 26 2009" e5f4b49 Re-adding ConfigurationPostProcessorTest
最近、社内で使用するシステムを内製する動きが出始めました。これまで開発経験のない人たちに、一通りの開発の流れを説明するために使用した情報をまとめておきます。 はじめに 大学や専門学校などでプログラミングを少々学んだものの、その後開発を特に行ってこなかった、ぐらいの人たちを想定しています。能力的には、プログラミングとは何かを一から教える必要がなく、但しgitやpyenv等を使った開発のお作法を知らないくらいの人たちです。 この記事では、こうした人たちに開発環境の用意から実際の開発環境の用意、展開の準備までに必要なタスクを説明することを想定しています。但し、各環境やコマンドの導入については言語やOS毎に手順が異なるため、説明を省きます。また、本記事で想定している言語はpythonやrubyなどの、最近のスクリプト言語です(つまりトラディショナルなCやC++などのコンパイル言語は想定しません)。
1. 使い始める 1.1 バージョン管理に関して 1.2 Git略史 1.3 Gitの基本 1.4 コマンドライン 1.5 Gitのインストール 1.6 最初のGitの構成 1.7 ヘルプを見る 1.8 まとめ 2. Git の基本 2.1 Git リポジトリの取得 2.2 変更内容のリポジトリへの記録 2.3 コミット履歴の閲覧 2.4 作業のやり直し 2.5 リモートでの作業 2.6 タグ 2.7 Git エイリアス 2.8 まとめ 3. Git のブランチ機能 3.1 ブランチとは 3.2 ブランチとマージの基本 3.3 ブランチの管理 3.4 ブランチでの作業の流れ 3.5 リモートブランチ 3.6 リベース 3.7 まとめ 4. Gitサーバー 4.1 プロトコル 4.2 サーバー用の Git の取得 4.3 SSH 公開鍵の作成 4.4 サーバーのセットアップ 4.5 Git
Jenkins の Git プラグインは標準で複数ブランチのビルドに対応してるんですが、1つのジョブで全部のブランチをビルドするので [成功 (master)] → [失敗 (branchA)] → [成功 (master)] → [失敗 (branchA)]みたいな感じでブランチごとの成功/失敗がわかりづらく、IRC に通知出してると FAILED! → Yippie! → FAILED! → Yippie! …とうるさい感じで残念です。 というわけで軽くググったところ、引っかかった↓を導入します。 Jenkins "Build Per Branch" by entagen インストール まずはドキュメントに書かれている通り、Jenkins にプラグインをいくつかインストール。 Git Plugin - Jenkins - Jenkins Wiki Gradle Plugin - Jen
ツイッタフォローしてやで(ﾎﾞｿｯ https://twitter.com/JotaroUT いろいろ使ってみたけどGitUp、やめられませんでした。 Macbookをスタバで開いてはプロジェクトをgitで管理する機会の多いであろう諸兄・諸姉のために、独断でイケてるなと思ったgitのGUIクライアントについて紹介したい。その名もGitUp。 GitUp : http://gitup.co/ GitUpとは GitUpはmacOS用に開発されたgitのGUIクライアントである。 公式ホームページに、 Work quickly, safely, and without headaches. とあるように、確かに使っている間は頭痛がしない気がする。大きな特徴としては、謳い文句の通り、 早い。 ざっくりした使い方 コミットを参照する。 ここでは、openFrameworks (https://op
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く