Как указать глубину оформления заказа (scm) в скриптовом конвейере - PullRequest
2 голосов
/ 03 октября 2019

репо нашего проекта очень большой (2,5 ГБ). Следовательно, на этапе извлечения (scm) в скриптовом конвейере клонированию кода из GIT требуется больше времени. и мы сталкиваемся с приведенными ниже ошибками, потому что GIT пытается получить всю историю.

Я до сих пор пробовал с checkout (scm), я прочитал в https://jenkins.io/doc/pipeline/steps/workflow-scm-step/, что есть опция под названиемглубина, на которую мы можем загрузить только последние коммиты.

Но я не знаю синтаксис для него.

node(nodeName) {
    try {
    deleteDir()
    checkout(scm)
        ....
        ....
    }
    catch(Exception ex) {
        throw ex
    }    
}

Если время клонирования сократится, это будет очень полезно. После выполнения проверки линии (scm),

Иногда мы получаем следующую ошибку.

using credential Servicejenkins_build
Cloning the remote Git repository
Cloning with configured refspecs honoured and without tags
Cloning repository 
hudson.plugins.git.GitException: Command "C:\Git\cmd\git fetch --no-tags --progress https://gitlab.com/../../supportforpc.git +refs/heads/*:refs/remotes/origin/*" returned status code 128:
stdout: 
stderr: remote: Enumerating objects: 1           
remote: Enumerating objects: 24671, done.        
remote: Counting objects:   0% (1/24671)           
remote: Counting objects:   1% (247/24671)           
remote: Counting objects:   2% (494/24671)           
remote: Counting objects:   3% (741/24671)           
remote: Counting objects:   4% (987/24671)           
remote: Counting objects:   5% (1234/24671)           
remote: Counting objects:   6% (1481/24671)  
.....
....
Counting objects:   100% (24671/24671) 
remote: Compressing objects:   0% (1/10279)           
remote: Compressing objects:   1% (103/10279)           
remote: Compressing objects:   2% (206/10279)           
remote: Compressing objects:   3% (309/10279)           
remote: Compressing objects:   4% (412/10279)           
remote: Compressing objects:   5% (514/10279)           
remote: Compressing objects:   6% (617/10279)           
remote: Compressing objects:   7% (720/10279)           
remote: Compressing objects:   8% (823/10279)           
remote: Compressing objects:   9% (926/10279)           
remote: Compressing objects:  10% (1028/10279) 
....
....
remote: Compressing objects:  100% (10279/10279) 
Receiving objects:   0% (1/24671)   
Receiving objects:   1% (247/24671)   
Receiving objects:   2% (494/24671)   
Receiving objects:   3% (741/24671)   
Receiving objects:   4% (987/24671)   
Receiving objects:   5% (1234/24671)   
Receiving objects:   6% (1481/24671)
....
....
Receiving objects:   43%

    fatal: index-pack failed
    error: RPC failed; curl 56 SSL read: 
    error:00000000:lib(0):func(0):reason(0), errno 10054

Поэтому я подумал, используя глубину 1 при проверке(scm) может решить проблему. Но я не знаю синтаксис в скриптовом конвейере.

1 Ответ

1 голос
/ 03 октября 2019

Вы можете включить мелкий клон (без истории и только самая последняя фиксация) в объекте scm перед извлечением:

node(nodeName) {
    try {
    deleteDir()
    scm.extensions << [$class: 'CloneOption', shallow: true]
    checkout(scm)
        ....
        ....
    }
    catch(Exception ex) {
        throw ex
    }    
}

Однако я бы посоветовал вам настроить иподдерживать репозиторий ссылок, который работает на порядок быстрее:

  1. В окне терминала клонируйте свой репозиторий в зеркало. Этот репозиторий будет содержать только объекты git:

    $ git clone --mirror https://gitlab.com/../../supportforpc.git
    Cloning into bare repository 'supportforpc.git'...
    remote: Enumerating objects: 6578, done.
    remote: Counting objects: 100% (6578/6578), done.
    remote: Compressing objects: 100% (1561/1561), done.
    remote: Total 739260 (delta 5791), reused 5046 (delta 5013), pack-reused 732682
    Receiving objects: 100% (739260/739260), 3.49 GiB | 3.78 MiB/s, done.
    Resolving deltas: 100% (562236/562236), done.
    
  2. Создать новое задание в Jenkins для периодического обновления зеркального репозитория. При обновлении зеркала используйте только команду fetch:

    sh "git fetch --all --prune"
    
  3. Скажите объекту scm использовать репозиторий зеркала в качестве ссылки. Удаленный репозиторий запрашивает новые коммиты после прочтения ссылки, поэтому вам не нужно постоянно обновлять зеркало:

    node(nodeName) {
        try {
        deleteDir()
        scm.extensions << [$class: 'CloneOption', reference: "<your-server>:git/<where-you-put-the-mirror-repo>"]
        checkout(scm)
            ....
            ....
        }
        catch(Exception ex) {
            throw ex
        }    
    }
    

После этогоПри установке вы увидите, что весь ваш репозиторий клонируется за считанные секунды, плюс вы можете сохранить всю историю репозитория. Вы можете протестировать клон для себя, если вы вручную клонировали из зеркального репозитория, созданного на шаге 1:

$ git clone <mirror-repository-directory> <some-dir>`
Cloning into '<some-dir>'...
done.
Checking out files: 100% (15055/15055), done.

Примечание относительно изменения объекта scm по умолчанию: если вы предпочитаете не изменять егоВы можете создать новый объект для оформления заказа, как показано в этот ответ :

checkout([
    $class: 'GitSCM',
    branches: scm.branches,
    doGenerateSubmoduleConfigurations: scm.doGenerateSubmoduleConfigurations,
    extensions: scm.extensions + [$class: 'CloneOption', reference: "<your-server>:git/<where-you-put-the-mirror-repo>"],
    userRemoteConfigs: scm.userRemoteConfigs
])
...