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

يوضح هذا البرنامج التعليمي كيف استخدمنا عامل ترميز Github Copilot لإعادة تشكيل مشروع إجراءات GitHub الشخصية وتعزيزها validate-file-exists. أصبح ما بدأ كأداة ترقيطي بشكل جيد منظمة ، ومغطاة باختبار ، وتوثيق ، وإعدادها للنجاح مع وضع وكيل Copilot وعامل الترميز.

سوف نسير من خلال مثالي على:

• التحديث تعليمات مخصصة Copilot لتحسين محاذاة المهمة.
• إنشاء copilot-setup-steps.yaml ملف لإعطاء وكيل الترميز الأدوات اللازمة في بيئته.
• العمل مع Copilot لتحديد الديون الفنية.
• التعاون مع Copilot في طلبات السحب.
• الشراكة مع Copilot لتحسين واجهة المستخدم بشكل تكراري في مشروع منفصل.

https://www.youtube.com/watch؟v=fwsj8caupt0

عمل github الذي بدأ كل شيء

مرة أخرى في نوفمبر 2024 ، قمت بإنشاء إجراءات github صغيرة تسمى validate-file-exists. أردت التأكد من بعض الملفات (مثل أ dependabot.yml ملف ، أو .github/copilot-instructions.md) كانت موجودة في مستودع. إذا لم يكن الأمر كذلك ، فإن سير عمل إجراءات GitHub سيفشل. دعمت المدخلات المفصولة للفاصلة وكان من المفترض أن تكون جزءًا من “خط الأساس” الأكبر من بوابات الجودة التي أستخدمها عبر المشاريع.

لقد كان وظيفيًا ، لكنني كنت أزيد من تحسينه. لقد كانت مستندات مفقودة ، وكان لديها بيانات تعريف غير متناسقة ، وبعض الثغرات في التحقق من صحة المدخلات ، ولم يكن لديها تعليمات مخصصة Copilot أو خطوات إعداد Copilot للمساعدة في تعيين Copilot للنجاح. حان الوقت لإصلاح ذلك – بمساعدة من وضع وكيل Copilot في VS Code.

الخطوة الأولى: تحسين التعليمات المخصصة

قبل إحضار الوكيل ، راجعت الموجود copilot-instructions.md. كان متناثرًا ، دون أي وصف لغرض المستودع أو استخدامه أو هيكله ، ولا أي إرشادات واضحة لـ Copilot.

فعل:

لقد استندت إلى التعليمات على أفضل الممارسات لاستخدام Copilot للعمل على المهام، من خلال توفير ملف تعليمات مخصصة للعينة في مطالبي ، واطلب من Copilot التحديث بناءً على قاعدة الشفرة. بمعنى آخر ، أردت أن توفر:

• ملخص واضح للمستودع/قاعدة الكود وما يفعله الإجراء.
• إرشادات المساهمة (كيفية بناء وتنسيق ونيصة واختبار قاعدة الكود ، بما في ذلك التوقعات قبل الالتزام).
• نظرة عامة على هيكل المشروع.
• المبادئ التقنية الرئيسية (TypeScript الصارمة ، التي تتضمن TSDOC ، ووظائف مركزة وقابلة للإدارة).

نتيجة:

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

# Validate File Exists Action

This is a TypeScript-based GitHub Action that validates whether specified files
exist in a repository. It takes a comma-separated list of files and validates
their existence, failing the workflow if any files are missing. Please follow
these guidelines when contributing:

## Code Standards

### Required Before Each Commit

- Run `npm run format:write` to ensure consistent code formatting with Prettier
- Run `npm run lint` to check for ESLint violations
- Run `npm run test` to ensure all tests pass
- Run `npm run local-action` to test the action locally with a `.env` file

### Development Flow

- Build: `npm run package` (compiles TypeScript and bundles with ncc)
- Test: `npm run test` or `npm run ci-test`
- Coverage: `npm run coverage` (generates coverage badge)
- Full check: `npm run all` (format, lint, test, coverage, package)
- Local testing: `npm run local-action` (test action locally with .env file)

## Repository Structure

- `src/`: Core TypeScript source code
  - `main.ts`: Main entry point and action orchestration
  - `fileValidator.ts`: Core file validation logic
  - `index.ts`: Action entrypoint that calls run()
  - `types.ts`: TypeScript type definitions
- `__tests__/`: Jest unit tests for all source files
- `dist/`: Compiled and bundled JavaScript output (generated)
- `action.yml`: GitHub Action metadata and interface definition
- `script/`: Release automation scripts
- `badges/`: Generated coverage and status badges

## Key Guidelines

1. Follow TypeScript strict mode and best practices
1. Use clear, descriptive variable and function names
1. Add TSDoc comments for all public methods and classes
1. Write comprehensive unit tests using Jest for all new functionality
1. Keep functions focused and manageable (generally under 50 lines)
1. Use consistent error handling with @actions/core.setFailed()
1. Validate inputs and provide meaningful error messages
1. Use @actions/core for all GitHub Actions integrations (inputs, outputs,
   logging)
1. Maintain backwards compatibility for action inputs/outputs

الخطوة الثانية: أضف copilot-setup-steps.yaml

مثل أي من المطورين منا ، يحتاج وكيل ترميز Copilot إلى بيئة مناسبة للعمل. وهذا يعني إعداد أي أطر مطلوبة ، وتثبيت التبعيات ، والتأكد من أن Copilot يمكنه الوصول إلى الأدوات المناسبة لإنجاز المهمة.

فعل:

لقد خلقت .github/copilot-setup-steps.yaml باستخدام مستندات github على تخصيص بيئة التطوير لوكيل ترميز Copilot. يقوم المثال بفحص الرمز ، ويقوم بإعداد Node.js ، ويقوم بتثبيت التبعيات المطلوبة. بالنظر إلى أن هذا هو إجراء TypeScript ، فهذا كل ما أحتاجه إلى حد كبير!

لقد قمت بتغيير بسيط واحد في سير العمل: تغيير النسخ العقدة ليتم الحصول عليه من .node-version ملف ، ليكون متسقا مع سير العمل الخاص بي CI:

- name: Setup Node.js
id: setup-node
uses: actions/setup-node@v4
with:
node-version-file: .node-version
cache: npm

نتيجة:

لدى وكيل ترميز Copilot التبعيات والأدوات اللازمة لإنشاء قاعدة الشفرة والترتيب واختبارها. نظرًا لأنه يجري تغييرات على قاعدة الشفرة ، فستكون قادرة على التحقق من الجودة (كما هو مطلوب في التعليمات المخصصة) باستخدام الأدوات التي تم تثبيتها في copilot-setup-steps.yml.

الخطوة الثالثة: دع Copilot تجد الدين الفني

مع خطوات الإعداد والتعليمات المخصصة ، فقد حان الوقت للعثور على مهمة. بالطبع ، التفت إلى CoPilot. باستخدام دردشة Copilot في VS Code ، سألنا Copilot:

“ما هو الديون الفنية الموجودة في هذا المشروع؟ يرجى إعطائي قائمة ذات أولويات من المجالات التي نحتاج إلى التركيز عليها. أود إنشاء مشكلة github مع أفضل 2 أو 3 عناصر. يرجى تضمين بيان مشكلة موجزة ، ومجموعة من معايير القبول ، ومؤشرات حول ما يجب إضافته/تحديث الملفات.”

في غضون دقائق ، استكشفت قاعدة الشفرة وعاد بقائمة من الاقتراحات:

• بيانات التعريف غير المتسقة.
• عدم تطابق README (أسماء الإدخال الخاطئة).
• لا التحقق من صحة المدخلات الفارغة أو المشوهة.

لاحظ كيف طلبنا بيان مشكلة ، ومعايير القبول ، والإرشادات على الملفات لإضافة/تحديث؟ هذه تأتي من أفضل الممارسات لاستخدام Copilot للعمل على المهام. وبعبارة أخرى ، تأكد من أن مشكلاتك محصورة بشكل جيد!

فعل:

طلبت من Copilot كتابة مشكلة تتناول هذه العناصر الثلاثة. بمجرد أن أنشأت المشكلة ، قمت بتعيينها إلى Copilot.

الخطوة الرابعة: وكيل ترميز Copilot في العمل

بمجرد تعيينه ، بدأ الوكيل طلب سحب جديد. إليك ما فعلته بشكل غير متزامن:

• استكشاف محتويات المستودع لبناء فهمه للمشكلة.
• أنشأت خطة بناء على استكشافها.
• إصلاح package.json الاسم ، الوصف ، عناوين URL ، وحقل المؤلف.
• تم تحديث أمثلة استخدام ReadMe لمطابقة الرمز.
• منطق التحقق من صحة الإدخال المضافة:
  • رفض السلاسل الفارغة أو البيضاء فقط.
  • رفض المدخلات التي هي مجرد فواصل.
• كتب أربعة اختبارات جديدة لهذه الحالات الحافة.
• وكانت التغطية المؤكدة ، والتنسيق ، والتغطية سليمة.
• تم تحديث هيئة طلب السحب مع قائمة مراجعة العمل.

أثناء تفويض المهمة إلى CoPilot ، أفرغت لي لشرح للجمهور ما كان يفعله ، وكيف تعمل خطوات وتعليمات Copilot في سياق جلسة الوكيل.

نتيجة:

أكمل Copilot جميع المهام في ما يزيد قليلاً عن 11 دقيقة. بعد مراجعة نهج الوكيل ، وافقت على سير عمل CI حتى يتمكن من تشغيل فحص الجودة القياسي على قاعدة الشفرة. فشل سير العمل ، ولكن من خلال عدم وجود خطأ من Copilot. كان لدي بعض عمليات تفتيش التخفيض الإضافية في CI التي لم تكن في التعليمات.

في الوقت الفعلي تصحيح الإصلاحات وإصلاحها

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

“كان إجراء github لدينا خطأ في وضع التخفيض ، هل يمكنك إصلاح ذلك من فضلك؟” (أيضا لصق الخطأ من سير العمل الإجراءات github.)

بعد بضع دقائق ، قام بتحديث الرمز ، ودفع التزام جديد ، وتم تمرير طلب السحب. وبينما كان Copilot يعمل على مهمتي في الخلفية ، تمكنت من اختتام الدفق.

المكافأة: إجراء تغييرات واجهة المستخدم مع وكيل ترميز Copilot وخادم MCP الكاتب المسرحي

بينما عملت CoPilot على تغييرات الكود الأولي لإجراء GitHub ، عرضت مشروعًا ثانيًا: أ تطبيق تصور الرادار الاتجاه ((ها هو المستودع) التي قمت بإنشائها باستخدام css next.js و tailwind CSS.

مشكلة:

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

• دع المستخدمين ينقرون على الرادار لوضع نقطة.
• تمكين إعادة وضع السحب والإفلات لتغيير فئة النقطة أو احتمالية.

حل:

لقد قدمت قضية github تصف UX ومعايير القبول والمراجع.

بعد بضع تكرارات للتعليقات من خلال العمل من خلال طلب السحب ، وكيل ترميز Copilot:

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

يتم تثبيت الكاتب المسرحي الآن بشكل افتراضي مع عامل ترميز Copilot ، والذي يتيح لـ Copilot التحقق من صحة السلوكيات البصرية أيضًا.

الأفكار النهائية

لم تكن هذه مجرد جلسة تنظيف. لقد كان درسًا في تعاون البرامج الحديث. وكيل ترميز Copilot هو زميلنا الجديد.

من خلال هيكلة مستودعاتنا مع السياق والنية ، ندعو Copilot للمساهمة بشكل مفيد.

إذا لم تكن قد جربت وكيل ترميز Copilot حتى الآن ، فكر من خلال مشاريعك الحالية:

• تنظيف عمل جيثب القديم.
• Refactor مستودع مهمل.
• إضافة عمليات التحقق والاختبارات.

قد تفاجأ مقدار التقدم الذي يمكنك إحرازه في فترة ما بعد الظهر.

---