لماذا تتخلى عن CI السحابي لصالح خط أنابيب على VPS الخاص بك
تُفوتر عروض CI السحابية بالدقيقة وتفرض طوابير انتظار مشتركة يزداد وقتها مع الحجم. ما إن تكبر المستودعات أو تتضاعف الاختبارات، حتى تتجاوز الفاتورة بسرعة تكلفة خادم VPS مخصّص. باستضافة Forgejo وWoodpecker CI على نفس الخادم، تختفي زمن الاستجابة الشبكي: يقرأ الـ runner الكود محليًا دون عبور بنية تحتية طرف ثالث. كما تختار أنت توقيت كل تحديث لخط الأنابيب، ولا يغادر أي سرّ من أسرار التكامل جهازك.
ما يضيفه Woodpecker CI على خادم VPS
- عزل Docker لكل خطوة — تعمل كل خطوة في حاويتها الخاصة دون حالة مشتركة بين الوظائف.
- بصمة ذاكرة صغيرة — يعمل خادم Woodpecker والعميل بأقل من 50 ميغابايت من RAM مجتمعَين.
- إعداد YAML بسيط — يكفي ملف
.woodpecker.yamlواحد في جذر المستودع لوصف خط الأنابيب كاملًا. - تكامل أصلي مع Forgejo — نظام OAuth2 في Forgejo هو الآلية الوحيدة للمصادقة المطلوبة، دون أي إضافة.
- رخصة Apache 2.0 — الكود المصدري قابل للتدقيق، والمجتمع fork نشط، دون اعتماد على مورّد مغلق.
المتطلبات المسبقة: خادم VPS مع Forgejo جاهز
يمكن تثبيت Woodpecker CI على نفس خادم VPS الذي يحتضن Forgejo أو على خادم مخصّص. للخدمتين معًا، خصّص 1 غيغابايت من RAM كحد أدنى و2 غيغابايت لاستخدام مريح مع عدة مستودعات نشطة. على الجانب البرمجي: Docker وDocker Compose، ونطاق فرعي مخصّص لـ Woodpecker (مثل ci.your-domain.com) يشير إلى عنوان IP الخادم، والمنفذ 443 مفتوح لـ HTTPS، ووصول SSH. يجب أن يكون Forgejo متاحًا من حاوية Woodpecker عبر الشبكة الداخلية لـ Docker أو عبر عنوانه العام.
نشر Woodpecker CI على خادم VPS
إنشاء تطبيق OAuth في Forgejo
في Forgejo، انتقل إلى الإعدادات ← التطبيقات ← إدارة تطبيقات OAuth2. أعطِ التطبيق اسمًا (مثل woodpecker) وأدخل عنوان إعادة التوجيه: https://ci.your-domain.com/authorize. دوّن معرّف العميل وسرّه المُولَّدَين.
كتابة ملف docker-compose.yml لـ Woodpecker
أنشئ /opt/woodpecker/docker-compose.yml بخدمتين: woodpecker-server (صورة woodpeckerci/woodpecker-server) وwoodpecker-agent (صورة woodpeckerci/woodpecker-agent). على الخادم، اضبط WOODPECKER_GITEA_URL وWOODPECKER_GITEA_CLIENT وWOODPECKER_GITEA_SECRET (قيم OAuth2 التي نسختها)، وWOODPECKER_AGENT_SECRET (سلسلة عشوائية مشتركة بين الخادم والعميل)، وWOODPECKER_HOST=https://ci.your-domain.com. يتلقّى العميل WOODPECKER_SERVER=woodpecker-server:9000 ونفس WOODPECKER_AGENT_SECRET.
تشغيل المجموعة
في /opt/woodpecker، نفّذ docker compose up -d. تحقّق من السجلات بـ docker compose logs -f woodpecker-server حتى ترى الخادم جاهزًا. تستمع الخدمة داخليًا على المنفذ 8000 (واجهة المستخدم) والمنفذ 9000 (gRPC للعميل).
تفعيل المستودع في Woodpecker
افتح https://ci.your-domain.com (خلف الوكيل العكسي) وسجّل دخولك بحسابك في Forgejo عبر OAuth2. في لوحة التحكم، انقر على «إضافة مستودع» وحدّد المشروع المراد تفعيله. يسجّل Woodpecker تلقائيًا webhook في Forgejo لتشغيل عمليات البناء.
إضافة ملف .woodpecker.yaml إلى المستودع
في جذر المستودع، أنشئ .woodpecker.yaml. مثال بسيط: خطوة lint تشغّل npm run lint في صورة node:20، وخطوة test تشغّل npm test، وخطوة deploy مشروطة بالفرع main وتنفّذ ssh deploy@your-domain.com ./deploy.sh. ادفع الملف: يُطلَق build فوري في Woodpecker.
ضع خادم Woodpecker خلف Traefik أو Caddy مع HTTPS ولا تكشفه مباشرةً على المنفذ 8000. خزّن جميع أسرار خط الأنابيب (رموز SSH، مفاتيح API للنشر) في قسم الأسرار الخاص بالمستودع في لوحة Woodpecker — تُحقَن كمتغيرات بيئة أثناء البناء دون أن تظهر في ملف .woodpecker.yaml المُضمَّن في الإصدار.
من forge git إلى النشر المستمر: مجموعة سيادية كاملة
يدير Forgejo الكود والمشكلات ومراجعات pull request؛ بينما يُنسّق Woodpecker CI خطوط أنابيب الاختبار والنشر. يتواصل الاثنان عبر OAuth2 والـ webhooks على شبكتك الخاصة، دون أي اعتماد على GitHub أو GitLab أو خدمة تكامل سحابية. تستجيب هذه المجموعة المُستضافة ذاتيًا لمتطلبات السيادة لدى الوكالات والفرق التقنية التي لا ترغب في مرور ملكيتها الفكرية أو أسرار تكاملها عبر منصات خارجية.
