باستخدام هدسون وبناء الخطوات مع عدة مخازن git

Question

أحاول الخروج هدسون إلى استبدال الحالي Buildbot الإعداد.لقد قمت بتثبيت بوابة المساعد.لدينا الإعداد الحالي مثل:

ssh://server:/repo/test_framework.git
ssh://server:/repo/project_a.git

الآن لبناء project_a لقد تم إضافة وظيفة جديدة مع عدة مخازن git (تلك المذكورة أعلاه).أردت هدسون إلى استنساخ مستودعات في دلائل مختلفة تحت $WORKSPACE, becase test_framework يحتاج هذا التسلسل الهرمي.ولكن هدسون أن دمج كل شيء في $WORKSPACE بدلا من ذلك.من وحدة التحكم تسجيل الدخول:

warning: no common commits
...
[workspace] $ git merge-base ce14a4579e87971659e5e0469136713847055a29 96d2b3c27595de243702414c4358366923696d78
[workspace] $ git merge-base ce14a4579e87971659e5e0469136713847055a29 5bb011b3fa288afd5e4392640b32b8bcc982103e
[workspace] $ git merge-base ce14a4579e87971659e5e0469136713847055a29 aa6ade81669883909ba5f5459a205df1bd0df3c0

هل يمكنني تكوين هذا في هدسون لتناسب أفضل مشروعنا الإعداد ؟ هل أنا بحاجة إلى دمية git مع كل مشروع بوابة الوحدات الفرعية أو ما شابه ؟

Answer 1

في هدسون يمكنك سلسلة متعددة الوظائف معا.قد تتمكن من محاولة خلق منفصلة هدسون وظائف test_framework وآخر project_a.هدسون يخلق دليل منفصل في مساحة العمل لكل وظيفة, حتى الآن يجب أن يكون لديك اثنين من الدلائل تحت $مساحة العمل.

---

إعداد تسلسل

في وظيفة تكوين project_a انتقل لأسفل إلى ما بعد بناء إجراءات التحقق من بناء مشاريع أخرى...أدخل في test_framework المشروع إلى بناء.

في وظيفة تكوين test_framework تضمن استطلاع المجلس الأعلى للقضاة دون رادع و ذلك بعد بناء مشاريع أخرى يتم تعيين project_a.

---

كيف يعمل

ما عليك الآن هو تكوين project_a سوف استطلاع SCM تبحث عن التغييرات ، عند إجراء تغييرات وجدت أنها ستسحب منهم من بوابة.تشغيل بناء الخطوات التالية (إن وجدت) على الانتهاء تؤدي test_framework العمل لسحب التغييرات من بوابة (إن وجدت) وتشغيل بناء على الخطوات التالية.

Answer 2

والمشكلة مع الحل "بناء مشاريع أخرى" غير أنه إذا كانت هناك تغييرات على test_framework فإنه لن يؤدي project_a للبناء. بدلا من ذلك، أوصي التخلي عن البرنامج المساعد بوابة واقامة بناء خطوة "تنفيذ قذيفة" بما يلي:

rm -rf ${WORKSPACE}/*

git clone ssh://server:/repo/test_framework.git ${WORKSPACE}/test_framework
cd ${WORKSPACE}/test_framework
git fetch -t ssh://user@server:/repo/test_framework.git +refs/heads/*:refs/remotes/origin/*
git ls-tree HEAD

git clone ssh://server:/repo/project_a.git ${WORKSPACE}/project_a
cd ${WORKSPACE}/project_a
git fetch -t ssh://user@server:/repo/project_a.git +refs/heads/*:refs/remotes/origin/*
git ls-tree HEAD

وبعد ذلك، إنشاء ملفات هوك "الخادم: /repo/test_framework.git/hooks/post-receive" و "الخادم: /repo/project_a.git/hooks/post-receive" مع المحتوى التالي:

#!/bin/sh
curl http://hudson/job/job_name/build

والآن، كلما دفعت التغييرات إما مستودع، وربط واستخدام API هدسون لتحريك البناء.

Answer 3

وأنا أدرك هذا السؤال هو قديمة جدا لكنني واجهت نفس المشكلة واستخدمت هذه الصفحة لتجسيد حل بلدي الذي يبدو أنه يعمل بشكل جيد حقا (على الرغم من أنه هو صبي معقد). معظم الفضل في هذا الحل يجب ان تذهب الى كلينتون (السبب الوحيد الذي أنا أن يكلف نفسه عناء تقديم هذه الإجابة هي أنه لا يبدو جوابه لمعالجة المستودعات المتعددة التي يجب أن تكون في الدليل قاعدة نفسه).

وافترض أن لديك اثنين من مستودعات (A و B).

الخطوات التالية:

1) تقديم مشروعين لسحب رمز من المستودعات بعد ألف وباء وضع أي خطوات بناء الضرورية في أي مستودع.

2) تقديم دليل ثالث دون أي إدارة التحكم بالمصادر. إضافة خطوة بناء على هذا المشروع لتنفيذ أمر قذيفة مشابهة لهذه:

ln -s /var/lib/jenkins/jobs/A/workspace A
ln -s /var/lib/jenkins/jobs/B/workspace B

و(مسارات الخاص بك قد لا تكون هي نفسها. انظر لهم حتى نفسك!)

والآن يمكنك إضافة أي خطوات بناء الأخرى التي تعتمد على ألف وباء يجري الأخوات في الدليل. ياي وصلات رمزية!

و3) سلسلة المهام الثلاث معا. ترتيب المهام سحب قد أو قد لا يهم (أنت تعرف أكثر مني) ولكن المهمة دون التحكم بالمصادر يجب أن تكون الحلقة الأخيرة في السلسلة.

Answer 4

وأنا واجهت نفس المشكلة وحلها حاليا من خلال إنشاء وظيفة لكل مشروع واستخدام في نسخ قطعة أثرية المساعد للسماح للبناء وظيفة تعتمد حتى لو يتم تحديث بوابة على انها تبعيات (هذا هو لتجنب بناء في وسط استكمالا للمشروع الذي نعتمد عليه) .

وهكذا project_a أن نسخ أحدث التحف مستقرة التي يحتاجها من test_framework وتحديثا لإطار اختبار من شأنه أن يؤدي بناء في project_a. لا يزال من الممكن تشغيلها project_a عن تغيير في بوابة، وأنها مجرد نسخ مرة أخرى أحدث القطع الأثرية في test_framework.

Answer 5

ويودع إن المشكلة التي تصف بالفعل كما خطأ في bugtracker جنكينز: الشبكي: / /issues.jenkins-ci.org/browse/JENKINS-8082

---

ونحن نستخدم الخيار "مساحة عمل مخصصة" في تكوين عمل المشروع الممتد على الخروج مستودع مهمتنا في في دليل فرعي من وظيفة أخرى.

وهذا يتحقق وظيفة أخرى خارج الدليل الرئيسي مع جميع الوحدات الفرعية:

var/lib/jenkins/jobs/
  + main_job
    + workspace (main git checkout with submodules)
      + modules
        + mod1
        + mod2
  + mod1_job (custom workspace set to main_job/workspace/modules/mod1)
    + workspace (empty)