Setup Github Actions and Test flows [P1]

Trước mắt tìm hiểu xem Github Actions & Github Workflows là gì đã

• Hiểu đơn giản em nó là 1 platform trên nền tảng Github cho phép chúng ta triển khai CI / CD với các actions thường làm như : Create PR / Merge etc …
• Chi tiết thêm về Github Actions

Tuy nhiên cần nói qua 1 chút về Runners

• Runner đơn giản là 1 em server và có thể chạy được 1 job / thời điểm
  • Thật chất runner là 1 service trên OS nên có thể setup nhiều runners / server

Setup & Install Environment with Runners

• Đầu tiên cần xác định environment này sẽ dùng cho mục đích gì
  • Nếu dính tới database thì chỉ nên 1 runner / server ( Sẽ rất phiền nếu chạy nhiều instance database / server, khi này phải mapping ports khác nhau để tránh conflict )
    • Suggest ta nên có 2 con Runners này ( same label ) để có thể multi jobs
  • Nếu chỉ dính tới chạy CS ( Code Standards ) check thì có thể >= 2 runners / server. Như vậy sẽ tận dụng được resource của server. Thực tế mình setup
    • 2 runners / Pi 4 8GB với PHP 8.1 php8.1
    • 2 runners / Pi 4 4GB với PHP 8.0 php8.0
    • 1 runner / Ubuntu x64 với PHP 8.1 php8.1

Bài toán Runners & Servers

Tạm xếp thứ tự về “sức mạnh” servers thì Pi 4 – 4G là thấp nhất rồi tới 8G và rồi là ubuntu ( do chạy trên 1 server AMD 5700G – 64GB RAM )

Do đó khi cần chạy các “code standards” check thì sẽ ưu tiên cho Pi, và khi chạy tới UnitTest thì qua ubuntu.

Parallel jobs

Về nguyên tắc các jobs đều được execute parallel, tuỳ thuộc vào available của các runners. Giả sử ta có flow sau

jobs:
  test1:
    runs-on: php8.0
    steps:
  test2:
    runs-on: php8.0
    steps:

2 jobs test1 & test2 đều sẽ được execute trên các runners có label là php8.0 . Và ở đây ta có 2 runners ( cùng 1 server ). Về cơ bản vẫn ổn thôi, nếu chưa đụng tới database.

Hình dung 2 jobs này chạy UnitTest và cần migrate database cũng như refresh database liên tục. Vậy thì … conflict chắc luôn

• Dù build qua docker thì cũng bị conflict port

Do đó sẽ cần restructure lại 1 chút bằng việc label unittest cho TỪNG SERVER. Như vậy ta có 3 servers : Pi 4 4GB / 8GB & Ubuntu.

jobs:
  test1:
    runs-on: unittest
    steps:
  test2:
    runs-on: unittest
    steps:

Vậy parallel mang lại ích lợi gì

Về mặt usage server thì tổng thời gian cũng như nhau. Vẫn sẽ bị tính khoảng 13m 27s tổng cộng. Tuy nhiên thực tế ta chỉ cần ít hơn rất nhiều. Khoảng 8m hơn.

• 6m đầu cho Test lâu nhất thuộc job build
• Do job Test Finished needs build do đó data phải chờ.
• Sau đó là 4m cho Test Flickr ( job lâu nhất )

Coverage

Vậy nếu mỗi TestSuite có coverage và cần gom lại để report cuối cùng thì sao. Logic đơn giản

• Chạy UnitTest trên từng job
• Sinh coverage
• Upload lên artifact
• Và tạo 1 job cuối cùng “Test finished” để download hết lại thành 1 cục và upload lên codecov

      - name: Download build from artifact
        uses: actions/download-artifact@v2
        if: success() && github.event.pull_request.draft == false
        with:
          name: coverage-reports
          path: ./reports

      - name: Upload coverage to codecov.io
        uses: codecov/codecov-action@v1
        if: success()
        with:
          directory: ./reports

To be continue