小 縮小字型大小。 中 重設字型大小。 大 放大字型大小。

標籤: PHP

為 Gitlab 加上 CI runner 做自動化測試

Posted on By 日落 在〈為 Gitlab 加上 CI runner 做自動化測試〉中尚無留言

gitlab-ci-runner 可以裝在 local 也可以跑在 docker container，我自己是安裝在 docker container：

docker run -d --name gitlab-runner --restart always 
  -v /srv/gitlab-runner/config:/etc/gitlab-runner 
  -v /var/run/docker.sock:/var/run/docker.sock 
  gitlab/gitlab-runner:latest

上面步驟完成以後，可以先進入 Gitlab 的 Admin => Runner，這邊會顯示 runner access token：

在該頁面可以找到 token，如果要讓之前設定的 token 失效，可以先點選「Reset」換一個 acces token：

先把 access token 複製下來，接下來建立一個 runner 並連接到 Gitlab 上：

docker exec -it gitlab-runner gitlab-runner register

設定說明：

  • gitlab-ci coordinator URL：輸入欲使用 runner 的 Gitlab 網址
  • gitlab-ci token：就是你剛剛複製下來的 access token
  • gitlab-ci description：輸入 runner 的名稱，例如 runner-php56 或是 runner-php70。這個名稱會在 Gitlab 上面看到，建議填寫清楚的名稱以供辨識。
  • executor：我這邊要讓 runner 在 docker container 裡面跑，所以選擇「docker」
  • Docker image：在 docker container 執行時，要使用哪個 image 當作 base。我自己懶的自己 built，用的是「edbizarro/gitlab-ci-pipeline-php」
  • gitlab-ci tags for this runner：這邊會請你輸入幾個關鍵字，假設在 project 設定中，出現這幾個關鍵字，則 Gitlab 會自動把符合的 executor on 起來跑。我自己會設定「docker」、「phptest」等等

到這邊若沒看到什麼錯誤，在 Gitlab 的 runner 頁面重新整理後，則頁面最下方可以看到剛剛設定好的 gitlab-ci description (runner name)：

這頁有看到的話，可以依樣畫胡驢，在需要使用到的專案 runner 設定頁面，使用這個 runner 來跑測試。

在 Gitlab 上將 runner 設定好，接下來只要在專案上加入「.gitlab.ci.yml」，當 git push 後 Gitlab 便會檔案中的設定自動把 executor on 起來跑，設定方法可以參考 Gitlab 提供的 gitlab-ci.yml 說明。

簡易的 PHP library (不包含任何 framework) project 的 .gitlab-ci.yml 大概長這樣：

image: edbizarro/gitlab-ci-pipeline-php:5.6


syntax-check:
    script:
        - "find . -name '*.php' -print0 | xargs -0 -n1 php -l"
    tags:
        - docker

unit-test:
    script:
        - composer install --prefer-dist --no-ansi --no-interaction --no-progress --no-scripts
        - ./vendor/bin/phpunit -v --coverage-text --colors=never --stderr
    tags:
        - docker

上面可以看到我要求 executor 一定要使用「edbizarro/gitlab-ci-pipeline-php:5.6」這個 image，不過由於 tasks 有特別設定 tags，所以這行也不是必要。

而這邊設定了二個 tasks 要求 executor 協助執行：「syntax-check」和「unit-test」。因此 executor 會先跑 syntax-check，確認沒有錯誤後，再去執行 unit-test。

完成後，只要 Gitlab 收到 commit 且就會依照 .gitlab-ci.yml 的設定下去跑。結果會自動顯示在「Pipeline」的列表當中：

Reference:

Tags:,

Laravel 5.3 的 API routing

Posted on By 日落 在〈Laravel 5.3 的 API routing〉中尚無留言

弄了很久才搞清楚 5.3 版的 routing 是怎麼搞的，覺得作者把事情弄的更複雜了，也少了一些彈性。

Laravel 5.3 中，routes 已經不是放在 App/Http 底下了，將設定獨立出來放在根目錄：

johnroyer@box:~/devel/laravel53$ tree routes
routes
├── api.php
├── console.php
└── web.php

有個 API 專用 routing 看了當然開心，只是怎麼樣都是不出來 api.php 這邊的設定要怎樣才能起作用。

後來找了很久才發現 Route 功能，已經在 provider 階段把 web / api 的 routing rule 寫死，所以 API 的 routing 有固定的 prefix，在網址是上必須是「http://laravel.root/api」開頭，才會吃到 api.php 的設定。該項 rule 被寫在 RouteServiceProvider 中：

    protected function mapApiRoutes()
    {
        Route::group([
            'middleware' => 'api',
            'namespace' => $this->namespace,
            'prefix' => 'api',
        ], function ($router) {
            require base_path('routes/api.php');
        });
    }

Reference:

Tags:, ,

phpBB 3.2 的 nginx 的 location 設定

Posted on By 日落 在〈phpBB 3.2 的 nginx 的 location 設定〉中尚無留言

先說一下 phpBB 安裝工具吧，安裝程式的路徑不是在跟目錄而是在「/install」，entry point 是 app.php，而 app.php 又有自己的 route。

 如果只是這樣設定的話，route 會失敗：

location / {
    try_files  $uri /index.php?$uri$args;
}

所以另外對「/install」增加了一個 rule 才能正常執行安裝工具：

location /install {
    try_files  $uri /app.php?$uri$args;
}

安裝完成後，論壇系統的有二個 entry point，所以不能只單設定 index.php，還有 app.php，因此 nginx 的設定要改成下面這樣：

location / {
    try_files  $uri /app.php?$uri$args /index.php?$uri$args;  # 注意順序
}

當然，安裝完成以後就可以把「/install」的設定砍掉了。

Tags:, ,

PHP copy-on-write 特性

Posted on By 日落 在〈PHP copy-on-write 特性〉中尚無留言

「copy on write」這個特性的意思是，在 variable 在沒有異動的時候，不會在記憶體中 re-allocate 一個新的區塊來存放資料，只有在被更新、修改或刪除資料時，才會另外將異動過的資料存放到記憶體其他區域。

剛看到時自己寫不知道這是什麼神奇的東西，看實例比較快。

先建立一個超級大的檔案 huge.log：

$content = file_get_contents('huge.log');

// 818.4 MB
echo sprintf("%.1f MBn", memory_get_peak_usage() / 1024 / 1024);

建立一個 function，這個 function 什麼事都不做，直接回傳我們傳進去的 $content：

$content = file_get_contents('huge.log');

function reply($content)
{
    return $content;
}

reply($content);

// 818.4 MB
echo sprintf("%.1f MBn", memory_get_peak_usage() / 1024 / 1024);

well … 我以前原本以為 pass by value，會另外將 variable clone 一份供 function 內部使用，但上面的 script 中呼叫了 reply() 以後，記憶體用量並沒有增加，所以將變數傳進 function 時，並沒有 clone 一份新的出來。

將原本的 reply() 稍做調整，在 return 之前新增一點東西到 $content 中：

function reply($content)
{
    return $content . 'some more';
}

reply($content);

// 1636.6 MB
echo sprintf("%.1f MBn", memory_get_peak_usage() / 1024 / 1024);

reply() 中對 $content 加了一些新的資料，這時候最大記憶體使用量就變為原來的 2 倍，很明顯 PHP 在記憶體 alloc 新的區塊來存放被修給過的 $content。所以「copy on write」的意思，就是這個資料被 write 時，PHP 才會要新的記憶體 (copy) 來存放有被修改過的資料。

處理大型資料時，可以利用這個特性來節省記憶體使用量。

例如：decorator() 這個 function 要對一個大型陣列的資料做處理：

function decorator($data)
{
    $sum = 0;
    foreach ($data as $item) {
        $sum += $item;
    }
    $data['average'] = $sum / count($data);
    $data['sum'] = $sum;

    return $data;
}

上面的 function 因為會修改 $data 的內容，所以 PHP 會 clone 一個 $data 再來做修改。

改成以下的寫法：

function decorator($data)
{
    $sum = 0;
    foreach ($data as $item) {
        $sum += $item;
    }

    $change = [
        'average' => $sum / count($data),
        'sum' => $sum,
    ];

    return $change;
}

foreach (decorator() as $key => $val) {
    $data[$key] = $val;
}

在 decorator() 並不會動到 $data 的內容，所以不需要 clone $data，而是在 function 執行結束以後，直接對 $data 做修改。這樣只需要多儲存 $change 陣列，和後續的處理動作，而不會讓使記憶體用量 double。

Tags: