قبلاً در مورد نحوه استفاده از GitHub Workflows برای به روز نگه داشتن وب سایت های “نیمه استاتیک” نوشته ام. این تکنیکی است که به نظر من واقعاً مفید است. وقتی آن پست وبلاگ را نوشتم، همه چیز بسیار ساده بود – شما انتخاب کردید که کدام شعبه وب سایت شما را نگه دارد (سنتی برای مدتی وجود داشت که از آن استفاده کنید. gh-pages) و اینکه آیا صفحات وب سایت در دایرکتوری ریشه مخزن یا دایرکتوری فراخوانی شده بودند /docs. من معمولا فایل های وب سایت خود را در آن قرار می دهم /docs دایرکتوری در master (اکنون main) شعبه و همه چیز به خوبی کار می کرد.
دلیل ذخیره سازی سایت در /docs به طوری که بین فایل هایی که برای تولید سایت استفاده می شد از خود سایت خروجی تولید شده جدایی وجود داشت. بسیاری از مخازن من دارای یک /tt دایرکتوری که حاوی الگوها است، a /data دایرکتوری که حاوی فایل های JSON یا پایگاه داده SQLite و a /bin دایرکتوری با a build برنامه ای که همه آن چیزها را با هم جمع می کند و انبوهی از فایل های HTML را تولید می کند که در نهایت به آن می رسند /docs فهرست راهنما. در پست اصلی وبلاگم در مورد این موضوع، یک تعریف گردش کار GitHub را نشان دادم که سایت را بازسازی می کند (هنگامی که فایل های ورودی تغییر می کنند یا طبق یک برنامه زمان بندی شده است) و هر فایل تغییر یافته را متعهد می کند. /docs فهرست راهنما. سپس مقداری جادوی GitHub اطمینان حاصل می کند که نسخه جدید سایت در سرور GitHub Pages مستقر شده است. همه چیز با دنیا خوب بود.
سپس، چند ماه پیش، اوضاع کمی پیچیده تر شد. ما گزینه هایی در مورد نحوه استقرار سایت GitHub Pages شما به دست آوردیم. نسخه استانداردی که قبلاً از آن استفاده می‌کردم «استقرار از یک شعبه» نام داشت، اما گزینه دیگری به نام «اقدامات GitHub» وجود داشت. به نظرم محتمل بود که واقعاً نیاز به استفاده از گزینه “GitHub Actions” داشتم، اما همه چیز همچنان به روش قبلی کار می کرد، و من چیزهای بسیار جالب تری برای بررسی داشتم، بنابراین همه چیز را به همان شکلی که بود رها کردم.
خوب، من می گویم که کارها هنوز به روش قدیمی کار می کردند … آنها بودند، اما یک چیز کمی متفاوت بود. به نظر می رسید که روش قدیمی توسط یک جریان کاری جدید GitHub به نام “pages-build-deployment” که به طور خودکار به تمام مخازنی که به آن نیاز داشتند اضافه شده بود، پشتیبانی می شد. و با نگاهی به جزئیات آن گردش کار، متوجه شدم که برخی از کارهای غیرضروری را در مخازن من انجام می دهد – برای مثال فرض می شود که سایت با استفاده از Jekyll ساخته می شود و این فقط برای چند مخزن من صادق است. برای اکثر آنها، این کار غیر ضروری بود. بنابراین من نیاز داشتم که گزینه استقرار جدید را با جزئیات بیشتری بررسی کنم.
من چند هفته پیش، با تغییر گزینه از “deploy from a branch” به “GitHub Actions” شروع کردم به این امید که، چون قبلا از GitHub Actions استفاده می کردم، همه چیز فقط کار می کند. اما متاسفانه اینطور نبود. سایت جدید من در حال ایجاد و متعهد به مخزن بود – اما تغییرات در سایت زنده نشان داده نمی شد. بنابراین من همه چیز را به عقب تغییر دادم تا زمانی که فرصت پیدا کردم جزئیات بیشتری را بررسی کنم.
آن زمان امروز بود. به نظر می رسید که من باید کدی را در گردش کار GitHub خود وارد کنم که در واقع استقرار سایت را در سرورهای GitHub Pages انجام دهد. یک جستجوی سریع در بازار GitHub Actions، اقدام سایت Deploy GitHub Pages را پیدا کرد که به نظر کار درستی بود. اما با خواندن مستندات، متوجه شدم که می‌خواهد سایت را از یک مصنوع مستقر کند، بنابراین ابتدا باید آن را ایجاد می‌کردم. و سپس مصنوع آپلود GitHub Pages را پیدا کردم که کار درست را انجام داد. بنابراین فقط موردی بود که این دو عمل را به روش صحیح به گردش کار خود اضافه کردم.
قبلاً، گردش کار من برای این سایت ها فقط به یک کار (به نام build) اما حالا یک را اضافه کردم deploy شغلی که به آن بستگی داشت build. برای مثال، گردش کاری که Planet Perl را می‌سازد اکنون به این شکل است:
name: Generate web page
on:
push:
branches: '*'
schedule:
- cron: '37 */4 * * *'
workflow_dispatch:
jobs:
build:
runs-on: ubuntu-latest
container: davorg/perl-perlanet:latest
steps:
- name: Checkout
uses: actions/checkout@v3
- name: Create pages
run: |
mkdir -p docs
perlanet > perlanet.log 2>&1
- name: Commit new page
if: github.repository == 'davorg/planetperl'
run: |
git config --global --add safe.directory /__w/planetperl/planetperl
GIT_STATUS=$(git status --porcelain)
echo $GIT_STATUS
git config user.name github-actions[bot]
git config user.email 41898282+github-actions[bot]@users.noreply.github.com
git add docs/
if [ "$GIT_STATUS" != "" ]; then git commit -m "Automated Web page generation"; fi
if [ "$GIT_STATUS" != "" ]; then git push; fi
- name: Archive perlanet logs
uses: actions/upload-artifact@v3
with:
name: perlanet.log
path: ./perlanet.log
retention-days: 3
- name: Update pages artifact
uses: actions/upload-pages-artifact@v1
with:
path: docs/
deploy:
needs: build
permissions:
pages: write
id-token: write
environment:
name: github-pages
url: ${\{ steps.deployment.outputs.page_url }}
runs-on: ubuntu-latest
steps:
- name: Deploy to GitHub Pages
id: deployment
uses: actions/deploy-pages@v1
بیت هایی که من اضافه کرده ام آخرین مرحله است build job (“به روز رسانی مصنوع صفحات”) و جدید deploy کار. تمام کدها عمدتاً از مستندات دو عملی که در بالا ذکر کردم کپی شده است.
با ایجاد این تغییرات در یکی از سایت‌های سیاره‌ام، روش استقرار را تغییر دادم و گردش کار را مجبور کردم اجرا شود. و از اینکه دیدم با موفقیت اجرا شد و نسخه جدید سایت به محض تغییر استقرار در URL زنده ظاهر شد بسیار خوشحال شدم.
این باعث خوشحالی من می شود زیرا احساس می کنم از استقرار صفحات GitHub به روشی که قرار است استفاده شود استفاده می کنم. من تمام سایت‌های سیاره‌ام را برای استفاده از این روش به‌روزرسانی کرده‌ام، اما چندین سایت دیگر دارم که باید در مقطعی به تغییر آنها بپردازم.
مثل همیشه وقتی چیز جدیدی در مورد یک ویژگی GitHub می‌فهمم، چند پیشنهاد دیگر برای بهبود به من می‌دهد:
- امکان فراخوانی یک گردش کار از دیگری وجود دارد. گردش کار سیاره همه بسیار شبیه به هم هستند. نمی‌دانم آیا می‌توانم یک گردش کار را تعریف کنم که همه کارها را انجام دهد و فقط آن را از تعریف گردش کار فردی فراخوانی کنم – پارامترهایی را برای رسیدگی به تفاوت‌ها ارسال کنیم.
- اکنون من سایت‌ها را از مصنوعات مستقر می‌کنم، نیازی نیست که سایت تولید شده واقعاً در مخزن وجود داشته باشد. این ممکن است چند چیز را کمی آسان تر کند.
به هر حال، فکر کردم آنچه را که امروز کشف کرده بودم به اشتراک بگذارم. آیا شخص دیگری از این طریق وب سایت تولید می کند؟ چگونه آن را انجام دهید؟
