تكوين الإنشاء لتطبيقات الويب الثابتة ل Azure
يتم تشغيل تكوين إنشاء تطبيقات الويب الثابتة من Azure إما بواسطة إجراءات GitHub أو خطوط أنابيب Azure. يحتوي كل موقع على ملف تكوين YAML يتحكم في كيفية إنشاء موقع ونشره. توضح هذه المقالة بنية الملف وخياراته.
يسرد الجدول التالي إعدادات التكوين المتوفرة.
| الخاصية | الوصف | مطلوب |
|---|---|---|
app_location |
يحتوي هذا المجلد على التعليمات البرمجية المصدر لتطبيق الواجهة الأمامية. القيمة مرتبطة بجذر المستودع في GitHub ومجلد العمل الحالي في Azure DevOps. عند استخدامها مع skip_app_build: true، هذه القيمة هي موقع إخراج إنشاء التطبيق. |
نعم |
api_location |
هذا المجلد الذي يحتوي على التعليمات البرمجية المصدر لتطبيق API الخاص بك. القيمة مرتبطة بجذر المستودع في GitHub ومجلد العمل الحالي في Azure DevOps. عند استخدامها مع skip_api_build: true، تكون هذه القيمة هي موقع إخراج إنشاء واجهة برمجة التطبيقات. |
لا |
output_location |
إذا كان تطبيق الويب الخاص بك يقوم بتشغيل خطوة إنشاء، فإن موقع الإخراج هو المجلد الذي يتم فيه إنشاء الملفات العامة. بالنسبة لمعظم المشاريع ، فإن output_location النسبة إلى app_location. ومع ذلك، بالنسبة لمشاريع.NET، يكون الموقع مرتبطا بمجلد إخراج النشر. |
لا |
app_build_command |
بالنسبة Node.js التطبيقات، يمكنك تحديد أمر مخصص لإنشاء تطبيق المحتوى الثابت. على سبيل المثال، لتكوين بنية إنتاج لتطبيق Angular إنشاء برنامج نصي npm المسمى build-prod للتشغيل ng build --prod والدخول npm run build-prod كأمر مخصص. إذا ترك فارغا، يحاول سير العمل تشغيل npm run build الأوامر أو npm run build:azure الأوامر. |
لا |
api_build_command |
بالنسبة Node.js التطبيقات، يمكنك تحديد أمر مخصص لإنشاء تطبيق واجهة برمجة تطبيقات Azure Functions. | لا |
skip_app_build |
قم بتعيين القيمة لتخطي true إنشاء تطبيق الواجهة الأمامية. |
لا |
skip_api_build |
قم بتعيين القيمة لتخطي true إنشاء وظائف واجهة برمجة التطبيقات. |
لا |
cwd(Azure Pipelines فقط) |
المسار المطلق إلى مجلد العمل. الإعدادات الافتراضية لـ $(System.DefaultWorkingDirectory). |
لا |
build_timeout_in_minutes |
قم بتعيين هذه القيمة لتخصيص مهلة الإنشاء. الإعدادات الافتراضية لـ 15. |
لا |
باستخدام هذه الإعدادات، يمكنك إعداد إجراءات GitHub أو خطوط أنابيب Azure لتشغيل التكامل المستمر/التسليم المستمر (CI/CD) لتطبيق الويب الثابت الخاص بك.
اسم الملف وموقعه
يتم إنشاء ملف التكوين بواسطة GitHub وتخزينه في المجلد .github/workflows ، المسمى باستخدام التنسيق التالي: azure-static-web-apps-<RANDOM_NAME>.yml.
ضبط البنية
يراقب تكوين النموذج التالي المستودع بحثا عن التغييرات. عندما يتم دفع الالتزامات إلى الفرع ، يتم إنشاء التطبيق من app_location المجلد ويتم تقديم الملفات الموجودة output_location فيه إلى main الويب العام. بالإضافة إلى ذلك، يتوفر التطبيق في مجلد API ضمن مسار الموقع api .
name: Azure Static Web Apps CI/CD
on:
push:
branches:
- main
pull_request:
types: [opened, synchronize, reopened, closed]
branches:
- main
jobs:
build_and_deploy_job:
if: github.event_name == 'push' || (github.event_name == 'pull_request' && github.event.action != 'closed')
runs-on: ubuntu-latest
name: Build and Deploy Job
steps:
- uses: actions/checkout@v2
with:
submodules: true
- name: Build And Deploy
id: builddeploy
uses: Azure/static-web-apps-deploy@v1
with:
azure_static_web_apps_api_token: ${{ secrets.AZURE_STATIC_WEB_APPS_API_TOKEN }}
repo_token: ${{ secrets.GITHUB_TOKEN }} # Used for GitHub integrations (i.e. PR comments)
action: "upload"
###### Repository/Build Configurations ######
app_location: "src" # App source code path relative to repository root
api_location: "api" # Api source code path relative to repository root - optional
output_location: "public" # Built app content directory, relative to app_location - optional
###### End of Repository/Build Configurations ######
close_pull_request_job:
if: github.event_name == 'pull_request' && github.event.action == 'closed'
runs-on: ubuntu-latest
name: Close Pull Request Job
steps:
- name: Close Pull Request
id: closepullrequest
uses: Azure/static-web-apps-deploy@v1
with:
azure_static_web_apps_api_token: ${{ secrets.AZURE_STATIC_WEB_APPS_API_TOKEN }}
action: "close"
في هذا التكوين:
- يتم
mainمراقبة الفرع للالتزامات. - يتم تشغيل سير عمل "إجراءات GitHub" عندما يكون طلب السحب على الفرع
main: مفتوحا أو متزامنا أو معاد فتحه أو مغلقا. - يتم
build_and_deploy_jobالتنفيذ عند دفع الالتزامات أو فتح طلب سحب ضد الفرع المدرج في مكانonالإقامة. - يشير
app_locationإلى المجلد الذيsrcيحتوي على الملفات المصدر لتطبيق الويب. لتعيين هذه القيمة إلى جذر المستودع، استخدم/. api_locationتشير إلى المجلد الذيapiيحتوي على تطبيق Azure Functions لنقاط نهاية واجهة برمجة التطبيقات الخاصة بالموقع. لتعيين هذه القيمة إلى جذر المستودع، استخدم/.- يشير
output_locationإلى المجلد الذيpublicيحتوي على الإصدار النهائي من الملفات المصدر للتطبيق. انها نسبة إلىapp_location. بالنسبة لمشاريع .NET، يكون الموقع مرتبطا بمجلد إخراج النشر.
لا تقم بتغيير قيم repo_token، actionوكما azure_static_web_apps_api_token تم تعيينها لك بواسطة Azure Static Web Apps.
أوامر إنشاء مخصصة
بالنسبة Node.js التطبيقات، يمكنك التحكم الدقيق في الأوامر التي يتم تشغيلها أثناء عملية إنشاء التطبيق أو واجهة برمجة التطبيقات. يوضح المثال التالي كيفية تعريف الإنشاء باستخدام قيم ل app_build_command و api_build_command.
ملاحظة
حاليا، يمكنك فقط تحديد app_build_command وللإصدارات api_build_command Node.js.
...
with:
azure_static_web_apps_api_token: ${{ secrets.AZURE_STATIC_WEB_APPS_API_TOKEN }}
repo_token: ${{ secrets.GITHUB_TOKEN }}
action: 'upload'
app_location: '/'
api_location: 'api'
output_location: 'dist'
app_build_command: 'npm run build-ui-prod'
api_build_command: 'npm run build-api-prod'
تخطي إنشاء تطبيق الواجهة الأمامية
إذا كنت بحاجة إلى التحكم الكامل في البنية لتطبيقك الأمامي، فيمكنك تجاوز الإنشاء التلقائي ونشر التطبيق المدمج في خطوة سابقة.
لتخطي إنشاء تطبيق الواجهة الأمامية:
- قم بتعيين
app_locationالملفات التي تريد نشرها إلى الموقع. - عيِّن
skip_app_buildإلىtrue. - تعيين
output_locationإلى سلسلة فارغة ('').
...
with:
azure_static_web_apps_api_token: ${{ secrets.AZURE_STATIC_WEB_APPS_API_TOKEN }}
repo_token: ${{ secrets.GITHUB_TOKEN }}
action: 'upload'
app_location: 'src/dist'
api_location: 'api'
output_location: ''
skip_app_build: true
تخطي إنشاء واجهة برمجة التطبيقات
إذا كنت ترغب في تخطي إنشاء واجهة برمجة التطبيقات، فيمكنك تجاوز الإنشاء التلقائي ونشر واجهة برمجة التطبيقات المضمنة في خطوة سابقة.
خطوات تخطي إنشاء واجهة برمجة التطبيقات:
- في الملف staticwebapp.config.json ، قم بتعيينه
apiRuntimeإلى وقت التشغيل والإصدار الصحيحين. راجع تكوين تطبيقات الويب الثابتة Azure للحصول على قائمة بأوقات التشغيل والإصدارات المدعومة.{ "platform": { "apiRuntime": "node:16" } } - عيِّن
skip_api_buildإلىtrue. - قم بالتعيين
api_locationإلى المجلد الذي يحتوي على تطبيق API الذي تم إنشاؤه لنشره. يرتبط هذا المسار بجذر المستودع في إجراءات GitHub وفيcwdخطوط أنابيب Azure.
...
with:
azure_static_web_apps_api_token: ${{ secrets.AZURE_STATIC_WEB_APPS_API_TOKEN }}
repo_token: ${{ secrets.GITHUB_TOKEN }}
action: 'upload'
app_location: "src" # App source code path relative to repository root
api_location: "api" # Api source code path relative to repository root - optional
output_location: "public" # Built app content directory, relative to app_location - optional
skip_api_build: true
تمديد مهلة الإنشاء
بشكل افتراضي ، يقتصر التطبيق وإصدارات واجهة برمجة التطبيقات على 15 دقيقة. يمكنك تمديد مهلة الإنشاء عن طريق تعيين build_timeout_in_minutes الخاصية.
...
with:
azure_static_web_apps_api_token: ${{ secrets.AZURE_STATIC_WEB_APPS_API_TOKEN }}
repo_token: ${{ secrets.GITHUB_TOKEN }}
action: 'upload'
app_location: 'src'
api_location: 'api'
output_location: 'public'
build_timeout_in_minutes: 30
متغيرات البيئة.
يمكنك تعيين متغيرات البيئة للإنشاء الخاص بك عبر env قسم تكوين المهمة.
...
with:
azure_static_web_apps_api_token: ${{ secrets.AZURE_STATIC_WEB_APPS_API_TOKEN }}
repo_token: ${{ secrets.GITHUB_TOKEN }}
action: 'upload'
app_location: 'src'
api_location: 'api'
output_location: 'public'
env: # Add environment variables here
HUGO_VERSION: 0.58.0
دعم مونوريبو
مونوريبو هو مستودع يحتوي على تعليمات برمجية لأكثر من تطبيق واحد. بشكل افتراضي، يتتبع سير العمل جميع الملفات الموجودة في مستودع، ولكن يمكنك ضبط التكوين لاستهداف تطبيق واحد.
لاستهداف ملف سير عمل إلى تطبيق واحد، يمكنك تحديد مسارات في الأقسام push والمقاطع pull_request .
عند إعداد monorepo، يتم تحديد نطاق كل تكوين تطبيق ثابت ليقتصر على ملفات تطبيق واحد فقط. تعيش ملفات سير العمل المختلفة جنبا إلى جنب في مجلد .github/workflows الخاص بالمستودع.
├── .github
│ └── workflows
│ ├── azure-static-web-apps-purple-pond.yml
│ └── azure-static-web-apps-yellow-shoe.yml
│
├── app1 👉 controlled by: azure-static-web-apps-purple-pond.yml
├── app2 👉 controlled by: azure-static-web-apps-yellow-shoe.yml
│
├── api1 👉 controlled by: azure-static-web-apps-purple-pond.yml
├── api2 👉 controlled by: azure-static-web-apps-yellow-shoe.yml
│
└── README.md
يوضح المثال التالي كيفية إضافة paths عقدة إلى push ملف وأقسامه pull_request باسم azure-static-web-apps-purple-pond.yml.
on:
push:
branches:
- main
paths:
- app1/**
- api1/**
- .github/workflows/azure-static-web-apps-purple-pond.yml
pull_request:
types: [opened, synchronize, reopened, closed]
branches:
- main
paths:
- app1/**
- api1/**
- .github/workflows/azure-static-web-apps-purple-pond.yml
في هذا المثال، تؤدي التغييرات التي تم إجراؤها على الملفات التالية فقط إلى تشغيل بنية جديدة:
- أي ملفات داخل مجلد app1
- أي ملفات داخل مجلد api1
- التغييرات التي تطرأ على ملف سير عمل azure-static-web-apps-purple-pond.yml الخاص بالتطبيق