آموزش ایجاد وب سایت صفحات گیت لب

در این مقاله به طور کامل با مراحل ایجاد GitLab page و دستورات کاربردی آن آشنا می شویم.

در این آموزش یک پروژه خالی ایجاد میکنیم و سپس یک فایل CI که وظیفه آن، انتقال دستورالعمل ها به runner است را برای خود ایجاد میکنیم. هنگامی که Pipeline CI/CD اجرا میشود، صفحات وب سایت ساخته میشوند.

در این مثال از Jekyll SSG که مخفف عبارت (Static Site Generator) است، استفاده میشود. در صورتی که بخواهید از SSG های دیگری استفاده کنید، مراحل راه اندازی آن تفاوت زیادی با Jekyll ندارد. برای متوجه شدن و درک این مقاله باید با مفهوم و وظایف Jekyll or SSGs آشنا باشید.

پیش نیازها

ابتدا یک پروژه خالی در گیت لب باز کنید. سپس 3 فایل زیر را در دایرکتوری (root (top-level ایجاد کنید:

gitlab-ci.yml.

فایل YAML شامل دستوراتی است که باید اجرا کنید. در حال حاضر با آن کاری نداریم پس فایل های آن را خالی میزاریم.

index.html

فایل HTML میتواند با هر نوع محتوایی که مربوط به HTML است، پر شود. به مثال زیر توجه کنید:

<html>

<head>

</head>

<body>

<h1>Hello World!</h1>

</body>

</html>

Gemfile

فایلی است که وابستگی یا dependency ها را برای برنامه های Ruby، توصیف میکند. این فایل با محتوا و عبارات زیر پر میشود:

source “https://rubygems.org”

gem “jekyll”

انتخاب یک Docker Image

در این مثال runner، از یک داکر ایمیج برای اجرای اسکریپت و توسعه استفاده میکند.

این ایمیج Ruby خاص، در داکرهاب (DockerHub) نگه داری میشود.

فایل .gitlab-ci.yml را ویرایش کنید و کد زیر را در خط اول آن وارد کنید:

image: ruby:2.7

نکته:

در صورتی که SSG مورد نظر شما برای ساخته شدن به NodeJS نیاز دارد، باید یک ایمیج مشخص کنید که فایل سیستم آن شامل NodeJS باشد. برای مثال، برای یک سایت مثل Hexo ، باید از image: node:12.17.0 استفاده کنید.

نصب Jekyll

برای اجرای Jekyll به صورت محلی، ابتدا باید پنجره ترمینال را باز کنید و دستورات زیر را وارد کنید:

1. اجرای دستور gem install bundler برای نصب Bundler.

2. اجرای دستور bundle install برای ایجاد Gemfile.lock

3. اجرای دستور bundle exec jekyll build برای نصب Jekyll.

اکنوندستورات زیر، در فایل gitlab-ci.yml. قرار دارد:

script:

– gem install bundler

– bundle install

– bundle exec jekyll build

در ادامه، در فایل gitlab-ci.yml. ، هر script با یک job سازماندهی شده است. job شامل اسکریپت ها و تنظیماتی است که برای انجام یک تسک خاص به آن نیاز دارید.

job:

script:

– gem install bundler

– bundle install

– bundle exec jekyll build

Job در صفحات گیت لب، یک اسم خاص به نام pages دارد. این تنظیمات به runner میگوید که شما یک job برای توسعه وب سایت با صفحات گیت لب دارید:

pages:

script:

– gem install bundler

– bundle install

– bundle exec jekyll build

برای خروجی یک دایرکتوری public تعیین کنید

Jekyll باید بداند که خروجی در کجا قرار است تولید شود.

صفحات گیت لب فقط شامل فایل هایی هستند که در دایرکتوری با نام public فراخوانی میشوند.

Jekyll هنگام ساخت وب سایت، برای تعیین یک دایرکتوری خروجی از (d-) استفاده میکند:

pages:

script:

– gem install bundler

– bundle install

– bundle exec jekyll build -d public

تعیین دایرکتوری public برای artifact ها

اکنون که Jekyll خروجی فایل های دایرکتوری public را دارد، runner ها نیاز دارند که بدانند کجا باید قرار بگیرند. Artifact ها در دایرکتوری public ذخیره شده اند:

pages:

script:

– gem install bundler

– bundle install

– bundle exec jekyll build -d public

artifacts:

paths:

– public

کد بالا را مانند زیر در فایل gitlab-ci.yml. پیست کنید:

image: ruby:2.7

pages:

script:

– gem install bundler

– bundle install

– bundle exec jekyll build -d public

artifacts:

paths:

– public

اکنون فایل gitlab-ci.yml. ذخیره و کامیت شده است. میتوانید اجرای Pipeline را با رفتن به CI/CD > Pipelines مشاهده کنید.

زمانی که اجرا آن با موفقیت انجام شد، برای نمایش URL جایی سایت در آن قابل دسترسی است، به Settings > Pages بروید.

اگر میخواهید تسک های پیشرفته تر بیشتری انجام دهید، می توانید فایل gitlab-ci.yml. خود را با تنظیماتی که در اختیار دارید آپدیت کنید. همچنین میتوانید فایل gitlab-ci.yml. خود را با ابزارهای CI LINT که در گیت لب قرار دارند، معتبر تر کنید.

بعد از اجرای موفق و صحیح pages JOB ، یک pages:deploy job جدید در نمای Pipeline ظاهر میشود که شامل محتوای وب سایت برای daemon صفحات گیت لب است. گیت برای اجرا شدن به runner نیازی ندارد و در بک گراند نیز اجرا میشود.

موضوعات زیر مثال های دیگری از ویژگی و option هایی که میتوان به فایل CI/CD اضافه کرد، را بیان میکنند.

توسعه branch های خاص برای صفحات سایت

ممکن است بخواهید صفحات سایت خود را فقط از طریق branch های خاص، توسعه دهید. برای انجام این کار مراحل زیر را دنبال کنید:

گام اول :

یک سکشن workflow برای قدرت بخشیدن به Pipeline فقط تا زمانی اجرا شود که تغییرات به branch فرستاده شوند:

image: ruby:2.7

pages:

script:

– gem install bundler

– bundle install

– bundle exec jekyll build -d public

artifacts:

paths:

– public

گام دوم :

Pipeline را جوری پیکربندی کنید که job ها را فقط برای master branch اجرا کند:

image: ruby:2.7

workflow:

rules:

– if: ‘$CI_COMMIT_BRANCH’

pages:

script:

– gem install bundler

– bundle install

– bundle exec jekyll build -d public

artifacts:

paths:

– public

rules:

– if: ‘$CI_COMMIT_BRANCH == “master”‘

تعیین یک stage برای توسعه

به طور کلی سه stage برای GitLab CI/CD وجود دارد:

Build , test و deploy

اگر بخواهید اسکریپت خود را تست کنید و ساختار سایت را قبل از توسعه محصول چک کنید، میتوانید test را دقیقا زمانی که به master منتقل می شوید، اجرا کنید. برای انجام این کار مراحل زیر را دنبال کنید:

گام اول :

برای تعیین کردن یک stage برای اجرای job، یک خط stage به فایل CI اضافه کنید:

image: ruby:2.7

workflow:

rules:

– if: ‘$CI_COMMIT_BRANCH’

pages:

stage: deploy

script:

– gem install bundler

– bundle install

– bundle exec jekyll build -d public

artifacts:

paths:

– public

rules:

– if: ‘$CI_COMMIT_BRANCH == “master”‘

گام دوم :

اکنون یک فایل job دیگر به فایل CI اضافه کنید، و به آن دستور دهید که هر انتقال به هر branch را تست کند به جز master branch :

image: ruby:2.7

workflow:

rules:

– if: ‘$CI_COMMIT_BRANCH’

pages:

stage: deploy

script:

– gem install bundler

– bundle install

– bundle exec jekyll build -d public

artifacts:

paths:

– public

rules:

– if: ‘$CI_COMMIT_BRANCH == “master”‘

test:

stage: test

script:

– gem install bundler

– bundle install

– bundle exec jekyll build -d test

artifacts:

paths:

– test

rules:

– if: ‘$CI_COMMIT_BRANCH != “master”‘

وقتی که عملیات test job در stage اجرا میشود، Jekyll سایت را در یک دایرکتوری به نام test میسازد. Job بر روی تمام branch ها به جز master اثر میگذارد.

وقتی که یک stage بر روی job ها مختلف انجام میدهید، هر job درون یک stage در parallel ساخته میشود. اگر برنامه تحت وب شما به تست بیشتری قبل از توسعه یافتن نیاز دارد، میتوانید تمام تست ها را در یک زمان اجرا کنید.

حذف دستورات duplicate یا تکراری

برای جلوگیری از به وجود آمدن اسکریپت های duplicate در هر job، میتوانید آنها را به یک سکشن before_script اضافه کنید.

برای مثال، دستورات gem install bundler و bundle install برای job های pages و test اجرا میشوند.

دستورات زیر را به یک سکشن before_script انتقال دهید:

image: ruby:2.7

workflow:

rules:

– if: ‘$CI_COMMIT_BRANCH’

before_script:

– gem install bundler

– bundle install

pages:

stage: deploy

script:

– bundle exec jekyll build -d public

artifacts:

paths:

– public

rules:

– if: ‘$CI_COMMIT_BRANCH == “master”‘

test:

stage: test

script:

– bundle exec jekyll build -d test

artifacts:

paths:

– test

rules:

– if: ‘$CI_COMMIT_BRANCH != “master”‘

ساخت سریعتر با dependence های کش شده

برای ساخت سریعتر پروژه، می توانید فایل های نصبی مربوط به پروژه های dependence را توسط پارامترهای cache، کش کنید.

مثال زیر، موقع اجرای bundle install در دایرکتوری vendor، وابستگی یا dependency های موجود در دایرکتوری را کش میکند:

image: ruby:2.7

workflow:

rules:

– if: ‘$CI_COMMIT_BRANCH’

cache:

paths:

– vendor/

before_script:

– gem install bundler

– bundle install –path vendor

pages:

stage: deploy

script:

– bundle exec jekyll build -d public

artifacts:

paths:

– public

rules:

– if: ‘$CI_COMMIT_BRANCH == “master”‘

test:

stage: test

script:

– bundle exec jekyll build -d test

artifacts:

paths:

– test

rules:

– if: ‘$CI_COMMIT_BRANCH != “master”‘

در چنین مواقع ای لازم است، دایرکتوری vendor/ را از لیست پوشه های ساخته شده توسط Jekyll جداسازی شود. از سوی دیگر، Jekyll تلاش میکند تا محتوای دایرکتوری را همراه با سایت بسازد.

در دایرکتوری root، یک فایل با اسم config.yml_ ایجاد کنید و دستور زیر را در آن وارد کنید:

exclude:

– vendor

اکنون GitLab CI/CD نه تنها وب سایت را ساخته، بلکه قابلیت های branch ها را به طور مداوم تست میکند، caches dependencies همراه با Bundler نصب شده و در هر master branch عملیات توسعه به طور مداوم انجام میشود.