أتمتة الاختبارات وإشعارات Slack باستخدام GitHub Actions: دليل شامل

مقدمة إلى GitHub Actions وأتمتة سير العمل

تُعد الأتمتة أداة بالغة القوة في عالم تطوير البرمجيات، فهي لا توفر الوقت الثمين فحسب، بل تساهم أيضاً في تقليل الأخطاء البشرية بشكل كبير. ومع ذلك، قد يكون تطبيق الأتمتة معقداً ومكلفاً في بعض الأحيان. فكيف يمكن لـ GitHub Actions أن تساعدنا في تعزيز جودة شيفرتنا وتوفير المزيد من الوقت للتركيز على تطوير الميزات بدلاً من إصلاح الأخطاء؟

ما هي GitHub Actions؟

GitHub Actions هي ميزة حديثة نسبياً أطلقتها GitHub، تتيح لك إعداد مسارات عمل (CI/CD workflows) متكاملة باستخدام ملف تهيئة بسيط يُحفظ مباشرة في مستودع GitHub الخاص بك. في السابق، إذا كنت ترغب في إعداد أي نوع من الأتمتة للاختبارات أو عمليات البناء أو النشر، كان عليك اللجوء إلى خدمات خارجية مثل Circle CI و Travis، أو كتابة نصوص برمجية مخصصة. لكن مع Actions، أصبح لديك دعم مباشر لأدوات قوية لأتمتة سير عملك بالكامل.

مفاهيم التكامل المستمر والنشر المستمر (CI/CD)

يشير مصطلح CI/CD إلى التكامل المستمر (Continuous Integration) والنشر المستمر (Continuous Deployment)، أو يمكن أن يكون التسليم المستمر (Continuous Delivery). وهما ممارستان أساسيتان في تطوير البرمجيات تتيحان للفرق بناء المشاريع معاً بسرعة وكفاءة، وبأقل قدر من الأخطاء.

• التكامل المستمر (Continuous Integration): يقوم على فكرة دمج الشيفرة من مختلف أعضاء الفريق الذين يعملون على فروع Git مختلفة في فرع عمل واحد. يتم بعد ذلك بناء هذه الشيفرة واختبارها باستخدام مسارات عمل مؤتمتة. يساعد هذا في ضمان أن شيفرة الجميع تعمل بشكل صحيح ومتكامل، وأنها خضعت لاختبارات شاملة باستمرار.
• النشر المستمر (Continuous Deployment): يأخذ هذه الأتمتة خطوة أبعد إلى مستوى النشر. فبينما تقوم عملية CI بأتمتة الاختبار والبناء، تتولى Continuous Deployment أتمتة نشر المشروع إلى بيئة التشغيل. الفكرة هي أن الشيفرة، بمجرد مرورها بعمليات البناء والاختبار، تكون في حالة قابلة للنشر، وبالتالي يجب أن تكون قادرة على النشر تلقائياً.

ماذا سنبني في هذا الدليل؟

سنتناول في هذا الدليل مساري عمل مختلفين. الأول هو تشغيل بعض الاختبارات المؤتمتة التي ستمنع دمج طلب السحب (pull request) إذا كانت الاختبارات فاشلة. لن نتطرق إلى بناء الاختبارات نفسها، بل سنركز على كيفية تشغيل الاختبارات الموجودة بالفعل. في الجزء الثاني، سنقوم بإعداد سير عمل يرسل رسالة إلى Slack تتضمن رابطاً لطلب السحب كلما تم إنشاء طلب جديد. يمكن أن يكون هذا مفيداً للغاية عند العمل على مشاريع مفتوحة المصدر مع فريق، حيث تحتاج إلى طريقة لتتبع الطلبات.

الجزء 0: إعداد المشروع

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

دالة مع اختبارين

إذا كنت ترغب في التحقق من هذا الكود للبدء، يمكنك تشغيل الأمر التالي:

git clone --single-branch --branch start git@github.com:colbyfayock/my-github-actions.git

بمجرد استنساخ المشروع محلياً وتثبيت التبعيات، يجب أن تكون قادراً على تشغيل الاختبارات ورؤيتها تمر بنجاح!

اختبارات تمر بنجاح

تجدر الإشارة أيضاً إلى أنه سيتعين عليك إضافة هذا المشروع كمستودع جديد على GitHub لتتمكن من المتابعة. تابع التغييرات في الالتزام (commit)!

الجزء 1: أتمتة الاختبارات البرمجية

تُعد الاختبارات جزءاً مهماً من أي مشروع، فهي تتيح لنا التأكد من أننا لا نكسر الشيفرة الموجودة أثناء عملنا. وعلى الرغم من أهميتها، فمن السهل نسيانها. يمكننا إزالة العامل البشري من المعادلة وأتمتة تشغيل اختباراتنا للتأكد من أننا لا نستطيع المتابعة دون إصلاح ما أفسدناه.

الخطوة 1: إنشاء إجراء جديد

الخبر السار هو أن GitHub يجعل بدء سير العمل هذا سهلاً للغاية، حيث يأتي كأحد الخيارات الجاهزة. سنبدأ بالانتقال إلى علامة التبويب Actions في صفحة المستودع الخاص بنا.

صفحة بدء GitHub Actions

بمجرد وصولنا إلى هناك، سنرى على الفور بعض مسارات العمل الأولية التي يوفرها GitHub لنا للبدء بها. بما أننا نستخدم مشروع Node.js، يمكننا المضي قدماً والنقر على Set up this workflow ضمن سير عمل Node.js.

إعداد سير عمل Node.js في GitHub Actions

بعد تحميل الصفحة، سيهبط بك GitHub إلى محرر ملف جديد يحتوي بالفعل على مجموعة من خيارات التهيئة المضافة. في الواقع، سنترك هذا “كما هو” لخطوتنا الأولى. اختيارياً، يمكنك تغيير اسم الملف إلى tests.yml أو أي اسم تتذكره.

إضافة ملف سير عمل جديد لـ GitHub Action

يمكنك المضي قدماً والنقر على Start commit ثم إما الالتزام به مباشرة بفرع master أو إضافة التغيير إلى فرع جديد. لهذا الدليل، سأقوم بالالتزام مباشرة بفرع master. لرؤية الإجراء الجديد يعمل، يمكننا مرة أخرى النقر على علامة التبويب Actions التي ستعيدنا إلى لوحة تحكم Actions الجديدة.

عرض أحداث سير عمل GitHub Action

من هناك، يمكنك النقر على Node.js CI وتحديد الالتزام الذي قمت به للتو أعلاه، وستصل إلى لوحة تحكم الإجراء الجديد. يمكنك بعد ذلك النقر على أحد إصدارات Node في الشريط الجانبي عبر build (#.x)، والنقر على القائمة المنسدلة Run npm test، وسنتمكن من رؤية مخرجات اختباراتنا وهي تعمل (والتي إذا كنت تتابع معي، يجب أن تمر بنجاح!).

عرض سجلات سير عمل GitHub Action

تابع التغييرات في الالتزام!

الخطوة 2: تهيئة الإجراء الجديد

ماذا فعلنا للتو أعلاه؟ سنتناول ملف التهيئة وما يمكننا تخصيصه.

ملف سير عمل Node.js في GitHub Action

بدءاً من الأعلى، نحدد الاسم (name):

name: Node.js CI

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

on:
  push:
    branches: [ master ]
  pull_request:
    branches: [ master ]

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

jobs:
  build:
    runs-on: ubuntu-latest

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

    strategy:
      matrix:
        node-version: [ 10.x, 12.x, 14.x ]

داخل مهمتنا، نحدد مصفوفة استراتيجية (strategy matrix). يتيح لنا هذا تشغيل نفس الاختبارات على عدة اختلافات. في هذه الحالة، نقوم بتشغيل الاختبارات على 3 إصدارات مختلفة من Node للتأكد من أنها تعمل على جميعها. هذا مفيد بالتأكيد للتأكد من أن شيفرتك مرنة ومستقبلية، ولكن إذا كنت تقوم ببناء وتشغيل شيفرتك على إصدار Node معين، فمن الآمن تغيير هذا إلى هذا الإصدار فقط.

    steps:
    - uses: actions/checkout@v2
    - name: Use Node.js ${{ matrix.node-version }}
      uses: actions/setup-node@v1
      with:
        node-version: ${{ matrix.node-version }}
    - run: npm ci
    - run: npm run build --if-present
    - run: npm test

أخيراً، نحدد الخطوات التي نريد أن تقوم بها مهمتنا. تفصيل هذا:

• uses: actions/checkout@v2: لكي نتمكن من تشغيل شيفرتنا، نحتاج إلى أن تكون متاحة. هذا يقوم باستنساخ شيفرتنا في بيئة المهمة حتى نتمكن من استخدامها لتشغيل الاختبارات.
• uses: actions/setup-node@v1: بما أننا نستخدم Node مع مشروعنا، فسنحتاج إلى إعداده في بيئتنا. نستخدم هذا الإجراء للقيام بهذا الإعداد لنا لكل إصدار حددناه في المصفوفة التي قمنا بتهيئتها أعلاه.
• run: npm ci: إذا لم تكن على دراية بـ npm ci، فهو مشابه لتشغيل npm install ولكنه يستخدم ملف package-lock.json دون إجراء أي ترقيات تصحيحية. لذا، يقوم هذا بشكل أساسي بتثبيت تبعياتنا.
• run: npm run build --if-present: يقوم npm run build بتشغيل نص البناء (build script) في مشروعنا. تقوم علامة --if-present بما توحي به وتنفذ هذا الأمر فقط إذا كان نص البناء موجوداً. لا يضر تركه لأنه لن يعمل بدون النص، ولكن لا تتردد في إزالته لأننا لا نقوم ببناء المشروع هنا.
• run: npm test: أخيراً، نقوم بتشغيل npm test لتشغيل اختباراتنا. يستخدم هذا نص npm للاختبار (test npm script) الذي تم إعداده في ملف package.json الخاص بنا.

وبهذا، قمنا بإجراء بعض التعديلات، ولكن يجب أن تعمل اختباراتنا بعد أن نلتزم بهذه التغييرات وتمر بنجاح كما كان من قبل!

سجلات الاختبارات الناجحة في سير عمل GitHub Action

تابع التغييرات في الالتزام!

الخطوة 3: اختبار فشل الاختبارات ومنع الدمج

الآن بعد أن تم إعداد اختباراتنا للتشغيل تلقائياً، دعنا نحاول كسرها لنرى كيف تعمل. في هذه المرحلة، يمكنك فعل ما تريده عمداً لكسر الاختبارات، ولكن هذا ما فعلته:

اختلاف الشيفرة بعد التغييرات الخاطئة

أقوم عمداً بإرجاع مخرجات متوقعة مختلفة بحيث تفشل اختباراتي. وقد فشلت بالفعل!

فشل فحوصات الحالة في طلب السحب

في طلب السحب الجديد الخاص بي، الفرع الجديد يكسر الاختبارات، لذلك يخبرني أن فحوصاتي قد فشلت. إذا لاحظت، لا يزال الزر أخضر للدمج (merge)، فكيف يمكننا منع الدمج؟

يمكننا منع دمج طلبات السحب عن طريق إعداد فرع محمي (Protected Branch) في إعدادات مشروعنا. أولاً، انتقل إلى Settings، ثم Branches، وانقر على Add rule.

إضافة قواعد حماية الفرع في GitHub

بعد ذلك، سنرغب في تعيين نمط اسم الفرع (branch name pattern) على *، مما يعني جميع الفروع، ثم نحدد خيار Require status checks to pass before merging، ثم نختار جميع فحوصات الحالة المختلفة التي نرغب في أن تمر بنجاح قبل الدمج.

إعداد قاعدة حماية الفرع في GitHub

أخيراً، انقر على Create في أسفل الصفحة. وبمجرد العودة إلى طلب السحب، ستلاحظ أن الرسالة مختلفة قليلاً وتشير إلى أننا بحاجة إلى أن تمر حالاتنا بنجاح قبل أن نتمكن من الدمج.

فشل الاختبارات يمنع الدمج في طلب السحب

ملاحظة: بصفتك مسؤولاً عن المستودع، ستظل قادراً على الدمج، لذا فإن هذا يمنع غير المسؤولين فقط من الدمج من الناحية الفنية. ولكنه سيزودك برسائل إضافية إذا فشلت الاختبارات. وبهذا، لدينا GitHub Action جديد يقوم بتشغيل اختباراتنا ويمنع دمج طلبات السحب إذا فشلت. تابع طلب السحب!

ملاحظة: لن نقوم بدمج طلب السحب هذا قبل المتابعة إلى الجزء الثاني.

الجزء 2: إرسال إشعارات طلبات السحب الجديدة إلى Slack

الآن بعد أن أصبحنا نمنع طلبات الدمج إذا كانت فاشلة، نريد إرسال رسالة إلى مساحة عمل Slack الخاصة بنا كلما تم فتح طلب سحب جديد. سيساعدنا هذا في تتبع مستودعاتنا مباشرة في Slack. لهذا الجزء من الدليل، ستحتاج إلى مساحة عمل Slack لديك أذونات لإنشاء تطبيق مطور جديد (developer app) بها، والقدرة على إنشاء قناة جديدة لمستخدم الروبوت (bot user) الذي سيتم ربطه بهذا التطبيق.

الخطوة 1: إعداد Slack

هناك بعض الأشياء التي سنتناولها أثناء إعداد Slack لسير عملنا:

• إنشاء تطبيق جديد لمساحة عملنا.
• تعيين أذونات لروبوتنا.
• تثبيت روبوتنا في مساحة عملنا.
• دعوة روبوتنا الجديد إلى قناتنا.

للبدء، سنقوم بإنشاء تطبيق جديد. توجه إلى لوحة تحكم Slack API Apps. إذا لم تكن قد سجلت الدخول بالفعل، فقم بتسجيل الدخول إلى حساب Slack الخاص بك مع مساحة العمل التي ترغب في إعداد هذا بها.

إنشاء تطبيق Slack جديد

الآن، انقر على Create New App حيث سيُطلب منك إدخال اسم وتحديد مساحة عمل تريد إنشاء هذا التطبيق لها. سأسمي تطبيقي “Gitbot“، ولكن يمكنك اختيار ما يناسبك. ثم انقر على Create App.

تهيئة تطبيق Slack جديد

بمجرد الإنشاء، انتقل إلى رابط App Home في الشريط الجانبي الأيسر. لاستخدام روبوتنا، نحتاج إلى تعيين نطاقات OAuth له حتى يكون لديه أذونات للعمل في قناتنا، لذا حدد Review Scopes to Add في تلك الصفحة.

مراجعة نطاقات تطبيق Slack

مرر لأسفل وسترى قسماً يسمى Scopes وتحته قسم Bot Token. هنا، انقر على Add an OAuth Scope. بالنسبة لروبوتنا، لا نحتاج إلى الكثير من الأذونات، لذا أضف نطاقي channels:join و chat:write، ويجب أن نكون جاهزين.

إضافة نطاقات لتطبيق Slack

الآن بعد أن أصبح لدينا نطاقاتنا، دعنا نضيف روبوتنا إلى مساحة عملنا. مرر لأعلى في نفس الصفحة إلى الأعلى وسترى زراً يقول Install App to Workspace.

تثبيت تطبيق Slack في مساحة العمل

بمجرد النقر على هذا، ستتم إعادة توجيهك إلى صفحة تفويض. هنا، يمكنك رؤية النطاقات التي حددناها لروبوتنا. بعد ذلك، انقر على Allow.

السماح بتثبيت تطبيق Slack في مساحة العمل

في هذه المرحلة، أصبح روبوت Slack الخاص بنا جاهزاً للعمل. في أعلى صفحة OAuth & Permissions، سترى رمز الوصول Bot User OAuth Access Token. هذا ما سنستخدمه عند إعداد سير عملنا، لذا إما أن تنسخ هذا الرمز وتحفظه أو تتذكر هذا الموقع حتى تعرف كيفية العثور عليه لاحقاً. ملاحظة: هذا الرمز خاص – لا تعطيه لأحد، أو تظهره في تسجيل شاشة، أو تدع أي شخص يراه!

نسخ رمز الوصول OAuth لمستخدم روبوت Slack

أخيراً، نحتاج إلى دعوة روبوت Slack الخاص بنا إلى قناتنا. إذا فتحت مساحة عملك، يمكنك إما استخدام قناة موجودة أو إنشاء قناة جديدة لهذه الإشعارات، ولكنك سترغب في إدخال الأمر /invite @[botname] الذي سيدعو روبوتنا إلى قناتنا.

دعوة مستخدم روبوت Slack إلى القناة

وبمجرد إضافته، نكون قد انتهينا من إعداد Slack!

تمت إضافة روبوت Slack إلى القناة

إنشاء إجراء GitHub لإرسال إشعارات إلى Slack

خطوتنا التالية ستكون مشابهة إلى حد ما عندما أنشأنا أول GitHub Action. سنقوم بإنشاء ملف سير عمل سنقوم بتهيئته لإرسال إشعاراتنا. بينما يمكننا استخدام محررات الأكواد الخاصة بنا للقيام بذلك عن طريق إنشاء ملف في دليل .github، سأستخدم واجهة مستخدم GitHub. أولاً، دعنا نعود إلى علامة التبويب Actions في مستودعنا. بمجرد وصولنا إلى هناك، حدد New workflow.

إعداد سير عمل جديد لـ GitHub Action

هذه المرة، سنبدأ سير العمل يدوياً بدلاً من استخدام إجراء جاهز. حدد set up a workflow yourself في الأعلى.

إعداد سير عمل GitHub Action يدوياً

بمجرد تحميل الصفحة الجديدة، ستجد نفسك في قالب جديد حيث يمكننا البدء في العمل. إليك كيف سيبدو سير عملنا الجديد:

name: Slack Notifications
on:
  pull_request:
    branches: [ master ]
jobs:
  notifySlack:
    runs-on: ubuntu-latest
    steps:
    - name: Notify slack
      env:
        SLACK_BOT_TOKEN: ${{ secrets.SLACK_BOT_TOKEN }}
      uses: abinoda/slack-action@master
      with:
        args: '{"channel":"[Channel ID]","blocks":[{"type":"section","text":{"type":"mrkdwn","text":"*Pull Request:* $ {{ github.event.pull_request.title }} "}},{"type":"section","text":{"type":"mrkdwn","text":"*Who?:* $ {{ github.event.pull_request.user.login }} \n*Request State:* $ {{ github.event.pull_request.state }} "}},{"type":"section","text":{"type":"mrkdwn","text":"<$ {{ github.event.pull_request.html_url }} |View Pull Request>"}}]}'

ماذا يحدث في الكود أعلاه؟

• name: نقوم بتعيين اسم سهل لسير عملنا.
• on: نريد أن يتم تشغيل سير عملنا عندما يتم إنشاء طلب سحب يستهدف فرع master الخاص بنا.
• jobs: نقوم بإنشاء مهمة جديدة تسمى notifySlack.
• jobs.notifySlack.runs-on: نريد أن تعمل مهمتنا على إعداد أساسي لأحدث إصدار من Ubuntu.
• jobs.notifySlack.steps: لدينا خطوة واحدة فقط هنا – نستخدم GitHub Action موجود مسبقاً يسمى Slack Action ونقوم بتهيئته لنشر إشعار إلى Slack الخاص بنا.

هناك نقطتان هنا سنحتاج إلى الانتباه إليهما، وهما env.SLACK_BOT_TOKEN و with.args. لكي يتواصل GitHub مع Slack، سنحتاج إلى رمز مميز (token). هذا ما نقوم بتعيينه في env.SLACK_BOT_TOKEN. لقد أنشأنا هذا الرمز في الخطوة الأولى. الآن بعد أن سنستخدمه في تهيئة سير عملنا، سنحتاج إلى إضافته كسر Git Secret في مشروعنا.

أسرار GitHub بما في ذلك SLACK_BOT_TOKEN

الخاصية with.args هي ما نستخدمه لتهيئة الحمولة (payload) إلى Slack API التي تتضمن معرف القناة (channel ID) ورسالتنا الفعلية (blocks). الحمولة في الوسائط محولة إلى سلسلة نصية (stringified) ومحمية (escaped). على سبيل المثال، عند توسيعها تبدو كالتالي:

{
  "channel": "[Channel ID]",
  "blocks": [
    {
      "type": "section",
      "text": {
        "type": "mrkdwn",
        "text": "*Pull Request:* ${{ github.event.pull_request.title }}"
      }
    },
    {
      "type": "section",
      "text": {
        "type": "mrkdwn",
        "text": "*Who?:*\n${{ github.event.pull_request.user.login }}\n*State:*\n${{ github.event.pull_request.state }}"
      }
    },
    {
      "type": "section",
      "text": {
        "type": "mrkdwn",
        "text": "<${{ github.event.pull_request._links.html.href }}|View Pull Request>"
      }
    }
  ]
}

ملاحظة: هذا فقط لإظهار كيف يبدو المحتوى، نحتاج إلى استخدام الملف الأصلي مع الوسيط المحول إلى سلسلة نصية ومحمي.

بالعودة إلى ملف التهيئة الخاص بنا، أول شيء نحدده هو معرف القناة (channel ID). للعثور على معرف القناة الخاص بك، ستحتاج إلى استخدام واجهة الويب الخاصة بـ Slack. بمجرد فتح Slack في متصفحك، سترغب في العثور على معرف القناة الخاص بك في عنوان URL:

https://app.slack.com/client/[workspace ID]/[channel ID]

معرف القناة في عنوان URL لتطبيق Slack الويب

باستخدام معرف القناة هذا، يمكنك تعديل تهيئة سير عملنا واستبدال [Channel ID] بهذا المعرف:

      with:
        args: '{"channel":"C014RMKG6H2",...

بقية خاصية الوسائط (arguments property) هي كيفية إعداد رسالتنا. تتضمن متغيرات من حدث GitHub التي نستخدمها لتخصيص رسالتنا. لن نتطرق إلى تعديلها هنا، حيث أن ما لدينا بالفعل سيرسل رسالة طلب سحب أساسية، ولكن يمكنك اختبار وبناء حمولتك الخاصة باستخدام Slack's Block Kit Builder. تابع التغييرات في الالتزام!

اختبار سير عمل إشعارات Slack

الآن بعد أن قمنا بتهيئة سير عملنا مع تطبيق Slack الخاص بنا، أخيراً نحن جاهزون لاستخدام روبوتنا! لهذا الجزء، كل ما نحتاجه هو إنشاء طلب سحب جديد مع أي تغيير نريده. لاختبار هذا، قمت ببساطة بإنشاء فرع جديد حيث أضفت جملة إلى ملف README.md.

اختلاف الشيفرة لطلب السحب التجريبي

بمجرد إنشاء طلب السحب هذا، على غرار سير عمل اختباراتنا، سيقوم GitHub بتشغيل سير عمل Slack الخاص بنا! يمكنك رؤية هذا يعمل في علامة التبويب Actions تماماً كما كان من قبل. طالما أنك قمت بإعداد كل شيء بشكل صحيح، بمجرد تشغيل سير العمل، يجب أن يكون لديك الآن رسالة جديدة في Slack من روبوتك الجديد.

رسالة آلية من روبوت Slack حول طلب سحب جديد

ملاحظة: لن نقوم بدمج طلب السحب هذا.

خيارات إضافية لتوسيع الأتمتة

تخصيص إشعارات Slack

الرسالة التي قمت بتجميعها بسيطة. تخبرنا من أنشأ طلب السحب وتوفر لنا رابطاً إليه. لتخصيص التنسيق والرسائل، يمكنك استخدام Github Block Kit Builder لإنشاء رسالتك الخاصة. إذا كنت ترغب في تضمين تفاصيل إضافية مثل المتغيرات التي استخدمتها لطلب السحب، يمكنك الاستفادة من سياقات Github المتاحة. يتيح لك هذا سحب معلومات حول البيئة والمهمة لتخصيص رسالتك. لم أتمكن من العثور على أي حمولات نموذجية، لذا إليك مثال على حمولة سياق github context payload نموذجية تتوقعها في الحدث.

حمولة سياق github نموذجية

المزيد من إجراءات GitHub

مع قدرتنا على إنشاء مسارات عمل مخصصة جديدة، لا يوجد الكثير مما لا يمكننا أتممته. لدى Github أيضاً سوق (marketplace) حيث يمكنك تصفح الإجراءات المختلفة. إذا كنت ترغب في اتخاذ خطوة أبعد، يمكنك حتى إنشاء الإجراء الخاص بك! يتيح لك هذا إعداد نصوص برمجية لتهيئة سير عمل لأداء أي مهام تحتاجها لمشروعك.

انضم إلى المحادثة! ما الذي تستخدم Github actions من أجله؟ شاركني على Twitter!

الخلاصة التقنية

تُظهر GitHub Actions كفاءة لا مثيل لها في تبسيط وأتمتة مهام تطوير البرمجيات الأساسية. من خلال دمج الاختبارات التلقائية وإشعارات Slack مباشرة في سير عمل Git، يمكن للفرق ضمان جودة الشيفرة بشكل استباقي، وتقليل الأخطاء البشرية، وتحسين التواصل. هذه القدرة على تخصيص مسارات العمل وإنشاء إجراءات مخصصة تفتح آفاقاً واسعة للابتكار، مما يجعل GitHub Actions أداة لا غنى عنها لأي فريق تطوير يسعى لتحقيق أقصى درجات الكفاءة والإنتاجية في بيئة CI/CD حديثة.