Jenkins betikli ardışık düzen veya bildirime dayalı ardışık düzen


101

Eski tarz proje temel iş akışımı Jenkins'e dayalı bir ardışık düzene dönüştürmeye çalışıyorum. Dokümanları incelerken scriptedve adında iki farklı sözdizimi olduğunu buldum declarative. declarativeSon zamanlarda yayınlanan Jenkins web sözdizimi gibi (2016 sonu). Yeni bir sözdizimi sürümü olmasına rağmen, Jenkins hala betik sözdizimini desteklemektedir.

Şimdi, bu iki türün her birinin hangi durumda en iyi eşleşme olacağından emin değilim. Öyleyse declarative, Jenkins boru hattının geleceği olacak mı?

Bu iki sözdizimi türü hakkında bazı düşünceler paylaşabilen herkes.


2
Komut dosyalarının kullanımdan kaldırılmasıyla ilgili hiçbir şey görmüyorum ve bu, bildirime dayalı ve komut dosyası yazılmış arasındaki özellik boşluğu göz önüne alındığında endişe verici olur.
Matt Schuchard

@MattSchuchard 3 yıl sonra hala haklı görünüyorsun. Şimdi bunu söz konusu olmadan düzenlemek için bir sıçrama yaptım.
cellepo

Yanıtlar:


90

Jenkins Pipeline ilk oluşturulduğunda, Groovy temel olarak seçildi. Jenkins, hem yöneticiler hem de kullanıcılar için gelişmiş komut dosyası oluşturma yetenekleri sağlamak için uzun süredir yerleşik bir Groovy motoruyla birlikte geldi. Ek olarak, Jenkins Pipeline'ın uygulayıcıları Groovy'nin artık "Scripted Pipeline" DSL olarak adlandırılan şeyin üzerine inşa edileceği sağlam bir temel olduğunu buldu.

Tam özellikli bir programlama ortamı olduğu için, Scripted Pipeline, Jenkins kullanıcılarına muazzam miktarda esneklik ve genişletilebilirlik sunar. Groovy öğrenme eğrisi, belirli bir ekibin tüm üyeleri için tipik olarak arzu edilmez, bu nedenle, Jenkins Pipeline'ı yazmak için daha basit ve daha kararlı bir sözdizimi sunmak için Bildirime Dayalı Ardışık Düzen oluşturuldu.

İkisi de temelde aynı Boru Hattı alt sistemidir. Her ikisi de "Kod olarak ardışık düzen" in dayanıklı uygulamalarıdır. Her ikisi de Pipeline'da yerleşik olan veya eklentiler tarafından sağlanan adımları kullanabilir. Her ikisi de Paylaşılan Kitaplıkları kullanabilir

Farklı oldukları yerde sözdizimi ve esneklik vardır. Bildirim, kullanıcı için mevcut olanı daha katı ve önceden tanımlanmış bir yapıyla sınırlandırır, bu da onu daha basit sürekli teslimat boru hatları için ideal bir seçim haline getirir. Scripted, yapı ve sözdizimi üzerindeki tek sınırların herhangi bir Pipeline'a özgü sistemlerden ziyade Groovy'nin kendisi tarafından tanımlanma eğiliminde olması nedeniyle çok az sınır sağlar, bu da onu ileri düzey kullanıcılar ve daha karmaşık gereksinimleri olanlar için ideal bir seçim haline getirir. Adından da anlaşılacağı gibi, Bildirim Ardışık Düzeni, bildirim temelli bir programlama modelini teşvik eder. Scripted Pipelines ise daha zorunlu bir programlama modelini takip eder.

Https://jenkins.io/doc/book/pipeline/syntax/#compare adresinden kopyalandı


5
Bir dizi bildirimsel ardışık düzen işini komut dizili ardışık düzene taşımaya çalıştım çünkü bunlar "ileri düzey kullanıcılar ve daha karmaşık gereksinimleri olanlar için ideal bir seçimdi". Komut dosyası olan ardışık düzen için neredeyse sıfır belge vardır. Yok. Bunun gibi neredeyse işe yaramaz. Bu, insanların farkında olması gereken büyük bir farktır.
cauchy

6
@cauchy hem betikli hem de bildirimsel ardışık düzenler için aynı dokümantasyon vardır, ancak komut dosyası gelişmiş kullanıcılar için olduğundan, ilk gösterilen değil, tüm dokümantasyon hem komut dosyası yazılmış hem de bildirimsel ardışık düzen belgeleri ve örnekleri içerir. Bildirime dayalı ardışık
düzenin

1
@ Ilhicas nerede? Kullanıcı el kitabında "geçiş" yoktur. Bağlantınız var mı? Komut dosyası oluşturulmuş ardışık düzen üzerindeki ardışık düzen adımları bile, bildirimsel ardışık düzen ve bildirime dayalı ardışık düzen belgelerine bağlantılar arasında hiçbir fark olmadığını söyler, bu da yanıltıcıdır.
cauchy

3
@cauchy örneği jenkins.io/doc/book/pipeline , aşağıda bildirimsel ardışık
düzeninin

Sorun, belgeleri düzgün bir şekilde okumamanıza bağlıdır, "Burada Bildirime Dayalı Ardışık Düzen sözdizimini kullanan bir Jenkinsfile örneği - Komut Dosyalı sözdizimi eşdeğerine aşağıdaki Komut Dosyalı Ardışık Düzenini Değiştir bağlantısına tıklayarak erişilebilir:" Bu, Resmi Belgelerdedir! Onlar gerçek tutarsanız Oku, o zaman .. Bu tür ifadeler yapabilirsiniz ..
Ilhicas

60

Dikkate alınması gereken başka bir şey de bildirimsel ardışık düzenlerin bir script () adımı olmasıdır . Bu, herhangi bir komut dosyası içeren ardışık düzeni çalıştırabilir. Bu yüzden benim tavsiyem, bildirim script()temelli ardışık düzenlerin kullanılması ve gerekirse komut dosyalı ardışık düzenlerin kullanılması olacaktır. Bu nedenle, her iki dünyanın da en iyisini elde edersiniz.


3
Bildirim temelli bir ardışık düzen içinde script () bloğu kullanma örneğiniz var mı? Bu bağlantının hiç yok.
user2023861

Kendinizi scriptbildirime dayalı bir ardışık düzen içinde birkaç kez bir blok kullanırken bulursanız , tüm yol boyunca komut dosyalı ardışık düzen kullanmayı düşünmelisiniz.
Kru

Tercihim, @CodyK'in bahsettiği gibi betikli ardışık düzenler yerine Bildirimli ardışık düzen. Evet, komut dosyalı ardışık düzenleri kullanabileceğimiz bazı karmaşık durumlar olduğuna katılıyorum. Ancak, prope basitleştirilmiş planlama her zaman karmaşıklığı azaltır ve çoğu zaman daha basit bildirimsel boru hattına giden yolu açacaktır.
NIK

18

Yakın zamanda kubernetes aracısı ile komut dosyasından bildirime geçiş yaptım. Temmuz '18'e kadar, bildirimsel ardışık düzenler kubernetes podlarını tam olarak belirtme yeteneğine sahip değildi. Ancak yamlFileadımın eklenmesiyle artık deponuzdaki bir yaml dosyasından pod şablonunuzu okuyabilirsiniz.

Bu daha sonra, pod şablonunuzu doğrulamak için vscode'un harika kubernetes eklentisini kullanmanıza, ardından bunu Jenkins dosyanıza okumanıza ve kapları istediğiniz adımlarla kullanmanıza olanak tanır.

pipeline {
  agent {
    kubernetes {
      label 'jenkins-pod'
      yamlFile 'jenkinsPodTemplate.yml'
    }
  }
  stages {
    stage('Checkout code and parse Jenkinsfile.json') {
      steps {
        container('jnlp'){
          script{
            inputFile = readFile('Jenkinsfile.json')
            config = new groovy.json.JsonSlurperClassic().parseText(inputFile)
            containerTag = env.BRANCH_NAME + '-' + env.GIT_COMMIT.substring(0, 7)
            println "pipeline config ==> ${config}"
          } // script
        } // container('jnlp')
      } // steps
    } // stage

Yukarıda belirtildiği gibi komut dosyası blokları ekleyebilirsiniz. Özel jnlp ve docker içeren örnek pod şablonu.

apiVersion: v1
kind: Pod
metadata:
  name: jenkins-pod
spec:
  containers:
  - name: jnlp
    image: jenkins/jnlp-slave:3.23-1
    imagePullPolicy: IfNotPresent
    tty: true
  - name: rsync
    image: mrsixw/concourse-rsync-resource
    imagePullPolicy: IfNotPresent
    tty: true
    volumeMounts:
      - name: nfs
        mountPath: /dags
  - name: docker
    image: docker:17.03
    imagePullPolicy: IfNotPresent
    command:
    - cat
    tty: true
    volumeMounts:
      - name: docker
        mountPath: /var/run/docker.sock
  volumes:
  - name: docker
    hostPath:
      path: /var/run/docker.sock
  - name: nfs
    nfs:
      server: 10.154.0.3
      path: /airflow/dags

1
Bu, yıl boyunca gördüğüm en yararlı cevap: Teşekkürler
Trevor Rudolph

14

bildirge, daha geleceğe yönelik ve insanların önerdiği seçenek gibi görünüyor. Visual Pipeline Editor'ün destekleyebileceği tek programdır. doğrulamayı destekler. ve çoğu bağlamda komut dosyalarına geri dönebileceğiniz için komut dosyası yazma gücünün çoğuna sahip olursunuz. Bazen birisi bildirimsel ile yapmak istediklerini tam olarak yapamayacakları bir kullanım senaryosu ile gelir, ancak bu genellikle bir süredir komut dosyası kullanan kişilerdir ve bu özellik boşluklarının zamanla kapanması muhtemeldir.

daha fazla içerik: https://jenkins.io/blog/2017/02/03/declarative-pipeline-ga/


4
Daha geleceğe dönük diye bir şey yoktur, farklı izleyicilere ve amaçlara hizmet ederler ve burada birçok başka yanıtta belirtildiği gibi her ikisi de aynı temel sisteme sahiptir. Bildirim, kullanıcıyı sınırlandırıyor, komut dosyası onlara çok fazla özgürlük veriyor, bu yüzden her birini uygulamak için farklı bilgi düzeylerinde jenkins olmanız gerekiyor.
Ilhicas

3
Size katılıyorum. bu cevap yazdığım zaman en iyisiydi, ancak jenkins yazarlarının farklılıkları şimdi daha iyi belgeledikleri ve senaryo yazısının yakın zamanda ortadan kalkmayacağını açıkça belirttikleri için mutluyum. :)
burnettk

7

Jenkins dokümantasyonu her iki türü de doğru bir şekilde açıklar ve karşılaştırır.

Alıntı yapmak gerekirse: "Scripted Pipeline, Jenkins kullanıcılarına muazzam miktarda esneklik ve genişletilebilirlik sunar. Groovy öğrenme eğrisi, genellikle belirli bir ekibin tüm üyeleri için arzu edilmez, bu nedenle Bildirici Ardışık Düzen, daha basit ve daha fikirli bir sözdizimi sunmak için Jenkins Pipeline yazarlığı.

İkisi de temelde aynı Boru Hattı alt sistemi. "

Daha fazlasını buradan okuyun: https://jenkins.io/doc/book/pipeline/syntax/#compare


2
  1. Bildirime dayalı ardışık düzen, 'ardışık düzen' olarak etiketlenmiş bir blok içinde tanımlanırken, komut dosyalı ardışık düzen bir 'düğüm' içinde tanımlanır.
  2. Sözdizimi - Bildirim ardışık düzeninde 'Aşamalar', 'Adımlar' vardır
  3. Derleme başarısız olursa, bildirimsel olan size derlemeyi bu aşamadan yeniden başlatma seçeneği sunar ve bu, komut dosyası seçeneğinde doğru değildir.
  4. Komut dosyası yazmada herhangi bir sorun varsa, bildirim niteliğinde olan, işi oluşturduğunuz anda sizi bilgilendirecek, ancak komut dosyası yazılması durumunda 'Tamam' olan aşamayı geçecek ve 'Tamam değil' olan aşamaya hata atacaktır.

Buna da başvurabilirsiniz. Çok İyi bir okuma -> https://e.printstacktrace.blog/jenkins-scripted-pipeline-vs-declarative-pipeline-the-4-practical-differences/ @ Szymon.Stepniak https://stackoverflow.com/users/ 2194470 / szymon-stepniak? Tab = profil


0

Bir de beni buraya getiren bu sorum var. Bildirime dayalı ardışık düzen kesinlikle tercih edilen yöntem gibi görünüyor ve ben şahsen onu daha okunaklı buluyorum, ancak orta düzey karmaşıklıktaki bir Freestyle işini Bildirime dönüştürmeye çalışıyorum ve en az bir eklenti buldum, Build Blocker eklentisi. bir adımda bir betik bloğunda bile çalıştırılamıyor (karşılık gelen "blockOn" komutunu her yerde şanssız olarak koymayı denedim ve dönüş hatası genellikle "Adımlar arasında böyle bir DSL yöntemi 'blockOn' bulunamadı" Bu yüzden eklenti desteğinin komut dosyası bloğunda bile ayrı bir sorun olduğunu düşünüyorum (bu konuda yanılıyorsam biri lütfen beni düzeltin) Basit davranışlar olarak düşündüğüm şeyi elde etmek için birkaç kez komut dosyası bloğunu kullanmak zorunda kaldım. derleme görünen adını ayarlamak gibi çalışır.

Deneyimlerimden dolayı, Bildirge için destek hala ihtiyacımız olan yere bağlı olmadığından, çalışmamı komut dosyası olarak yeniden yapmaya eğilimliyim, ancak bunun gelecekteki en kanıtlayıcı seçenek olduğunu kabul ettiğim için talihsiz bir durum ve resmi olarak destekleniyor. Belki bir seçim yapmadan önce kaç eklenti kullanmayı düşündüğünüzü düşünün.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.