* Artikel ini berisi link iklan untuk UpCloud VPS
Pengiriman berkelanjutan dan integrasi berkelanjutan adalah metodologi pengembangan perangkat lunak tangkas yang mempersingkat waktu siklus antara perubahan kode dan penerapan. Dengan menggunakan otomatisasi untuk memverifikasi perubahan kode dan membuat file rilis, tim dapat menjadi lebih produktif dan efisien.
Perusahaan perangkat lunak telah mempraktikkan pengembangan berkelanjutan sejak lama, tetapi Anda juga dapat menggunakan metode ini untuk proyek FPGA Anda. Tutorial ini mengajarkan Anda cara menyiapkan server otomatisasi di Virtual Private Server (VPS) menggunakan Jenkins, Xilinx Vivado, dan sistem manajemen kontrol sumber (SCM) Git/Github.
Server otomatisasi Jenkins adalah program sumber terbuka dan gratis yang ditulis dalam Java. Ini berjalan di Windows atau Linux. Kami akan menggunakan Linux dalam postingan blog ini karena itulah platform paling umum untuk server tanpa kepala.
Jenkins berjalan sebagai proses daemon di Linux atau sebagai layanan di Windows. Server web internal yang diluncurkan Jenkins saat dimulai menyediakan antarmuka pengguna. Sebagian besar pengguna akan berinteraksi dengan Jenkins menggunakan antarmuka web. Anda dapat menambahkan proyek otomatisasi baru dan mengelola proyek yang sudah ada melalui GUI web.
Gambar di atas menunjukkan halaman utama server Jenkins yang akan kita siapkan hari ini. Secara default, hanya pengguna yang login yang dapat mengakses Jenkins, namun untuk artikel ini, saya telah mengaktifkan akses publik ke bagian *server demo saya.
* Pembaruan:Saya menghapus server demo pada 13 Mei 2020
Apa yang Anda lihat di halaman utama adalah daftar pekerjaan. Pekerjaan ini dapat berisi tugas apa pun, dan dapat dipicu secara manual dari GUI web. Atau dapat dipicu secara otomatis melalui skrip, webhook, atau sebagai hasil penyelesaian tugas lainnya. Oleh karena itu istilah server otomasi .
Dalam contoh kita, setiap pekerjaan berhubungan dengan modul VHDL yang disimpan di repositori GitHub terpisah. Kami akan membuat Jenkins menjalankan simulasi dan membangun proyek setiap kali pengembang memasukkan kode ke salah satu repo Git yang dipantau. Jika testbench gagal atau build rusak, Jenkins akan menandai pekerjaan tersebut sebagai gagal di antarmuka web dan secara otomatis mengirim email ke orang yang melakukan kode yang salah.
Server otomatisasi paling berguna untuk tim yang mengerjakan proyek yang lebih besar. Oleh karena itu, saya telah membuat contoh proyek FPGA yang terdiri dari delapan repositori Git. Proyek ini adalah penghitung tampilan 7 segmen dari kursus Fast-Track yang di-porting ke Xilinx ZedBoard.
Tautan ke delapan repo di GitHub:
Setiap repo berisi modul VHDL dan testbench-nya. Pengecualiannya adalah paket repo, yang hanya berisi tiga paket VHDL yang mendefinisikan konstanta dan tipe. Selain itu, seg7 modul teratas berisi file batasan yang menentukan kecepatan jam dan penetapan pin implementasi fisik.
Sebagian besar proyek VHDL skala besar menggunakan modul dari lebih dari satu repositori. Perusahaan biasanya memiliki perpustakaan paket dan modul yang mereka gunakan kembali dalam banyak desain. Itulah yang saya tiru dengan membagi desain yang agak sederhana ini menjadi banyak modul.
Dalam contoh kita, semua modul bergantung pada paket repo, dan modul teratas juga bergantung pada semua submodul. Saya telah memecahkan masalah ini dengan mengimpornya sesuai kebutuhan dengan menggunakan Submodul Git standar. Grafik di atas menunjukkan konten dan dependensi semua repo dalam proyek ini.
Repositori Git juga berisi beberapa file non-desain, seperti konfigurasi Jenkins dan skrip build. Kami akan membicarakannya di bagian selanjutnya artikel ini.
Meskipun Jenkins dapat dijalankan di komputer Windows atau Linux mana pun, untuk semua tujuan praktis, Anda sebaiknya menjalankannya di server khusus. Server otomatisasi harus selalu aktif dan berjalan serta dapat diakses oleh semua anggota tim Anda. Jika Anda memiliki server fisik dengan kapasitas yang cukup, itu bagus. Namun bagi sebagian besar dari kita, solusi yang lebih cepat dan murah adalah dengan menggunakan server pribadi virtual (VPS).
VPS adalah komputer virtual yang Anda sewa dari perusahaan hosting melalui internet. Tampaknya seperti komputer Windows atau Linux asli tempat Anda dapat berinteraksi dan menginstal perangkat lunak apa pun yang Anda inginkan. Kami akan menggunakan komputer Linux karena itulah yang paling masuk akal untuk kasus penggunaan kami.
Situs VHDLwhiz berjalan pada VPS, seperti yang terjadi selama dua tahun terakhir. Saya sudah bersusah payah mencari penyedia VPS tercepat dan terbaik, yaitu UpCloud. Biasanya, kami akan menggunakan UpCloud untuk menyiapkan VPS untuk server otomatisasi kami.
Jika Anda ingin mencoba UpCloud, saya memiliki kode rujukan yang akan memberi Anda kredit senilai $25 saat mendaftar.
>> Klik di sini untuk mendapatkan bonus UpCloud $25 <<
Atau gunakan kode promo saya saat checkout:NV78V6
Dengan menggunakan kode tersebut, Anda akan mendapatkan bonus dan dukungan VHDLwhiz sekaligus. Saya mungkin mendapatkan sejumlah dana yang dikreditkan ke akun UpCloud saya untuk setiap pelanggan yang menggunakannya.
Oke, cukup dengan pembicaraan penjualannya. Mari kita lanjutkan dengan menyiapkan server.
Setelah Anda masuk ke akun UpCloud baru Anda, Anda dapat memulai proses pembuatan instance VPS baru dengan menavigasi ke Server → Deploy server .
UpCloud memiliki banyak pusat data di seluruh dunia. Pilih lokasi terdekat dengan Anda untuk menghosting server baru Anda. Kemudian Anda harus memilih rencana berapa banyak sumber daya yang akan diberikan kepada mesin virtual Anda. Jenkins tidak menggunakan banyak sumber daya, tetapi Xilinx Vivado benar-benar boros RAM. Oleh karena itu, Anda sebaiknya memilih setidaknya paket dengan RAM 4 GB, seperti yang ditunjukkan pada gambar di bawah.
Saya sarankan untuk melihat halaman Rekomendasi Memori Xilinx karena penggunaan memori berkaitan erat dengan kompleksitas target FPGA. Halaman ini mencantumkan penggunaan memori puncak untuk FPGA Zynq-7000 XC7Z045 yang saya gunakan adalah 1,9 GB. Saya menemukan bahwa paket 2 GB terlalu kecil untuk merutekan desain. Vivado mogok, dan pesan berikut muncul di dmesg catatan:
[807816.678940] Kehabisan memori:Proses terhenti 22605 (vivado) total-vm:2046684kB, anon-rss:782916kB, file-rss:308kB, shmem-rss:0kB
Perhatikan bahwa Anda selalu dapat meningkatkan sumber daya RAM dan CPU server Anda dengan mudah dari dalam akun UpCloud Anda. Anda tidak akan secara otomatis mendapatkan ruang hard drive tambahan yang disertakan dengan paket yang lebih mahal tanpa mempartisi ulang sistem file VPS, tetapi sistem file tersebut akan berjalan. Sebagai referensi, saya memulai paket dengan penyimpanan 50 GB, dan saya telah menggunakan 61% dari penyimpanan tersebut setelah menyelesaikan seluruh server otomatisasi. Vivado sendiri memakan ruang sebesar 24 GB.
Saya menyarankan Anda memilih distribusi CentOS Linux terbaru sebagai sistem operasinya, seperti yang ditunjukkan pada gambar di bawah ini. Xilinx Vivado secara resmi hanya mendukung Red Hat Linux, yang tidak gratis. Namun CentOS adalah distribusi Linux gratis yang didukung komunitas dan mengikuti jejak Red Hat.
Lalu ada beberapa opsi tentang jaringan yang dapat Anda biarkan default. Ada juga bagian di halaman web tempat Anda dapat mengunggah kunci SSH untuk login tanpa kata sandi. Anda selalu dapat mengonfigurasi hal-hal ini nanti menggunakan metode Linux konvensional untuk mengunggah kunci SSH.
Terakhir, Anda perlu menentukan nama host dan nama server, seperti yang ditunjukkan pada gambar di bawah. Nama host adalah domain publik yang akan dimasukkan pengguna ke dalam browser untuk mengakses server Jenkins. Jika Anda belum menyiapkan domain atau subdomain, Anda selalu dapat mengakses server menggunakan alamat IP-nya. Jika Anda puas dengan pengaturannya, tekan tombol Deploy tombol untuk membuat server.
Setelah Anda membuat server, kata sandi yang dibuat secara otomatis akan ditampilkan sebagai pemberitahuan. Anda dapat mengubahnya nanti, menggunakan passwd Linux perintah. Jika Anda memberikan kunci SSH sebelum menerapkan server, Anda tidak memerlukan kata sandi sama sekali. Jika Anda kehilangan akses ke server, Anda selalu dapat masuk dari dalam akun UpCloud Anda dengan menekan Buka koneksi konsol , seperti yang ditunjukkan pada gambar di bawah ini.
Server baru akan diberi alamat IPv4 dan IPv6 permanen, yang dapat ditemukan di akun UpCloud Anda di Server->Jaringan . Anda dapat mengakses server dengan melakukan SSH ke akun root alamat IPv4 publik.
Dengan menggunakan contoh alamat IP dari gambar di bawah, perintah yang tepat untuk dimasukkan ke komputer rumah Linux Anda adalah:
Tidak masalah jika Anda hanya menggunakan alamat IP jika Anda melakukan ini hanya sebagai percobaan. Namun solusi yang lebih praktis adalah dengan menetapkan nama domain permanen ke server. Untuk melakukannya, Anda harus membeli domain dari salah satu dari banyak registrar yang tersedia secara online.
Karena saya sudah memiliki domain vhdlwhiz.com, saya memutuskan untuk membuat subdomain untuk server Jenkins dengan nama jenkins.vhdlwhiz.com . Kami menyiapkan nama domain dengan benar di server UpCloud saat kami menerapkannya. Hal berikutnya yang perlu kita lakukan adalah mengarahkan subdomain ke alamat IPv4 publik.
Gambar di bawah menunjukkan pengaturan yang saya masukkan di file zona DNS pendaftar nama domain saya. Jika saya ingin server berada di domain teratas (vhdlwhiz.com), saya akan membiarkan bidang nama host kosong. Tapi saya ingin itu ada di subdomain “jenkins” di vhdlwhiz.com. Oleh karena itu saya masukkan nama subdomainnya.
Diperlukan beberapa saat setelah mengubah pengaturan DNS sebelum Anda dapat menggunakan nama domain untuk mengakses situs web Anda. Biasanya, perubahan ini memerlukan waktu tidak lebih dari 20 menit, namun dalam kasus ekstrem, diperlukan waktu hingga 48 jam agar perubahan diterapkan ke seluruh penjuru internet.
Ketika perubahan sudah diterapkan, Anda dapat menggunakan nama domain alih-alih alamat IP saat masuk ke server melalui SSH:
ssh root@yoursub.yourdomain.com
Hal pertama yang harus Anda lakukan setelah masuk ke akun root di server Linux baru Anda adalah memperbarui semua paket yang diinstal. Di CentOS Linux, nyaman adalah manajer paket default. Kita akan menggunakan yum perintah untuk menginstal sebagian besar perangkat lunak.
Keluarkan perintah berikut untuk memperbarui semua paket yang diinstal ke versi terbaru:
Sekarang setelah kami mengetahui bahwa sistem kami sudah yang terbaru, kami dapat melanjutkan instalasi. Namun sebelum mengeluarkan yum perintah untuk menginstal Jenkins, kita akan menginstal Java versi 11, secara eksplisit. Itu akan menyelamatkan kita dari masalah nanti ketika kita menginstal Xilinx Vivado.
Saat ini, tidak ada juru bahasa Java di server kami, dan jika kami memberi tahu yum untuk menginstal Jenkins, itu akan menginstal Java versi 8. Itu berfungsi dengan baik untuk Jenkins, tetapi nanti akan menimbulkan masalah bagi kami karena Vivado bergantung pada Java versi 11.
Instal Java 11 menggunakan perintah ini sebelum menginstal Jenkins:
yum -y install java-11-openjdk-devel
Jenkins tidak tersedia di repositori perangkat lunak default yang disertakan dengan CentOS. Untungnya, kita dapat mengimpor repo Jenkins dari Red Hat dengan menggunakan perintah berikut:
wget -O /etc/yum.repos.d/jenkins.repo https://pkg.jenkins.io/redhat/jenkins.repo rpm --import https://pkg.jenkins.io/redhat/jenkins.io.key
Terakhir, kita dapat melanjutkan dan menginstal Jenkins:
Server Jenkins akan mulai secara otomatis setelah boot berikutnya, tetapi Anda dapat memulai server tanpa melakukan boot ulang seperti ini:
Anda selalu dapat memeriksa status server Jenkins dengan menggunakan systemctl perintah:
Ini akan mencetak status server beserta pesan kesalahan apa pun:
Pada titik ini, Jenkins berjalan pada port 8080 di VPS, tetapi Anda tidak memiliki cara untuk menghubungkannya dengan browser web Anda. Itu karena firewall CentOS memblokir port 8080 dan port 80 (HTTP) secara default. Yang bisa kita lakukan untuk memperbaikinya adalah dengan membuka port 80 di firewall dan merutekannya ulang ke port 8080 menggunakan iptables .
Namun sebelum melakukannya, Anda harus memutuskan apakah Anda ingin mengamankan situs Anda dengan HTTPS. Masalah dengan hanya menggunakan HTTP dan port 80 adalah situs web Anda akan menjadi tidak aman. Jika Anda mengaksesnya menggunakan Wi-Fi publik, orang jahat di Wi-Fi yang sama dengan laptop dan perangkat lunak peretasan yang tersedia dapat menguping koneksi Anda dan mencuri kredensial login Anda ke Jenkins.
Jika Anda ingin menghindari risiko keamanan HTTP yang tidak terenkripsi, lanjutkan ke bagian berikutnya tentang menyiapkan HTTPS untuk Jenkins. Jika tidak, teruslah membaca.
Mengaktifkan akses HTTP tidak aman ke Jenkins semudah mengeluarkan perintah berikut:
firewall-cmd --permanent --zone=public --add-port=80/tcp firewall-cmd --reload iptables -A PREROUTING -t nat -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 8080
Kemudian Anda dapat memasukkan nama domain Anda di browser favorit Anda, dan Memulai Jenkins halaman akan muncul. Setidaknya di Google Chrome, peringatan “Tidak aman” akan ditampilkan di bilah alamat, seperti yang ditunjukkan pada gambar di bawah ini.
Lewati ke Menyiapkan Jenkins bagian jika Anda senang dengan itu.
Memiliki situs web tidak aman yang dapat diakses oleh publik merupakan risiko keamanan yang sangat besar. Jenkins dapat mengakses kode sumber Anda, begitu pula peretas mana pun yang berhasil membobol server. Untungnya, mengamankan situs web hanya dengan beberapa perintah salin-tempel.
Jenkins tidak bisa menangani HTTPS sendiri. Oleh karena itu, kita harus menginstal server web umum untuk merutekan ulang permintaan yang datang melalui saluran aman ke server Jenkins yang tidak aman. Saya akan menggunakan Nginx, yang merupakan salah satu server web sumber terbuka dan gratis terpopuler saat ini.
Keluarkan perintah berikut untuk menginstal dan memulai Nginx:
yum -y install nginx systemctl start nginx
Kemudian kita perlu membuka port HTTP dan HTTPS di firewall. Kami hanya akan melayani permintaan HTTPS, namun kami juga harus menjaga port HTTP tetap terbuka karena kami akan mengonfigurasi Nginx untuk mengalihkan semua permintaan tidak aman ke port aman.
Perintah berikut akan membuka firewall untuk lalu lintas web:
firewall-cmd --permanent --zone=public --add-port=80/tcp firewall-cmd --permanent --zone=public --add-port=443/tcp firewall-cmd --reload
Langkah selanjutnya adalah memasang sertifikat yang dapat digunakan browser web untuk menyatakan bahwa mereka berinteraksi dengan situs web Anda dan bukan penipu. Kami akan menggunakan otoritas sertifikat Let's Encrypt gratis untuk mengamankan situs kami. Langkah-langkah individualnya rumit, tapi untungnya, certbot menyediakan skrip yang dapat melakukannya untuk kita secara otomatis.
Download dan siapkan scriptnya dengan perintah berikut:
apt update apt install snapd snap install core; snap refresh core snap install --classic certbot
Selanjutnya, jalankan skrip, yang akan menginstal sertifikat dan membuat perubahan yang diperlukan pada file konfigurasi Nginx:
Saat skrip berjalan, Anda akan dimintai informasi. Jawablah dengan tegas (Ya, Terima) untuk semua pertanyaan hingga Anda diminta untuk memilih apakah akan mengalihkan lalu lintas HTTP ke HTTPS atau tidak. Daftar di bawah ini menunjukkan pertanyaan, dan jawaban yang saya sarankan (2). Mengizinkan Nginx mengalihkan permintaan yang tidak aman akan memastikan bahwa tidak ada orang yang dapat memasukkan http:// secara eksplisit situs Anda.com dan mendapatkan versi Jenkins yang tidak aman. Nginx akan mengarahkan mereka ke versi aman.
... Deploying Certificate to VirtualHost /etc/nginx/nginx.conf Please choose whether or not to redirect HTTP traffic to HTTPS, removing HTTP access. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 1: No redirect - Make no further changes to the webserver configuration. 2: Redirect - Make all requests redirect to secure HTTPS access. Choose this for new sites, or if you're confident your site works on HTTPS. You can undo this change by editing your web server's configuration. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Select the appropriate number [1-2] then [enter] (press 'c' to cancel): 2
Terakhir, Anda harus mengaktifkan tugas cron untuk memperbarui sertifikat secara berkala. Jika tidak, situs Anda akan kedaluwarsa dan browser akan menolak membuka situs Anda sama sekali.
Keluarkan perintah satu baris berikut untuk menambahkan tugas cron harian:
echo "0 0 * * * /snap/bin/certbot renew --quiet" | crontab -
Daemon cron akan menjalankan skrip pembaruan setiap hari pada tengah malam. Anda dapat membuat daftar tugas cron dengan crontab -l perintah dan edit dengan crontab -e perintah. Jika Anda mengunjungi situs web Anda sekarang, Anda akan melihat halaman pengujian Nginx, dan bukan Jenkins. Kami akan segera memperbaikinya, namun pastikan peringatan “Tidak aman” hilang dari bilah alamat Chrome, seperti yang ditunjukkan gambar di bawah.
Untuk membuat Nginx melayani Jenkins, Anda perlu membuat beberapa perubahan pada /etc/nginx/nginx.conf mengajukan. Penghargaan untuk cuplikan kode ini diberikan kepada blog Kerren di Medium. Menggunakan editor nano mungkin merupakan cara termudah untuk mengedit file konfigurasi:
nano /etc/nginx/nginx.conf
Temukan blok server yang mencantumkan nama domain Anda dan tambahkan baris yang disorot dari daftar di bawah ini ke file nginx.conf Anda. Perhatikan bahwa baris pertama dari tiga baris baru berada di atas blok server, dan sisanya masuk ke blok lokasi akar.
Setelah Anda memperbarui file konfigurasi, Anda perlu memuat ulang Nginx agar perubahan diterapkan. Secara opsional, Anda dapat menguji file konfigurasi sebelum memuat ulang dengan menggunakan perintah:
Nginx akan mencetak OK atau memberi tahu Anda baris mana di nginx.conf ajukan kesalahannya. Jika Anda puas dengan perubahannya, Anda dapat memuat ulang server web dengan memberikan perintah berikut:
Saat Anda mengunjungi situs Jenkins di browser Anda, Anda akan melihat halaman Memulai Jenkins, seperti yang ditunjukkan pada gambar di bawah. Kali ini disajikan melalui koneksi aman, dan kami dapat terus mengonfigurasi Jenkins dengan aman dari dalam antarmuka GUI web.
Saat pertama kali Anda mengunjungi situs web Jenkins, Anda akan dimintai kata sandi yang ditemukan dalam file di sistem file Linux. Saat masuk melalui SSH, gunakan perintah di bawah ini untuk menampilkan kata sandi. Salin-tempel ke browser untuk mendapatkan akses ke GUI web:
cat /var/lib/jenkins/secrets/initialAdminPassword
Di layar berikutnya, Jenkins akan menanyakan apakah Anda ingin menginstal plugin yang disarankan, atau Anda ingin menentukan plugin mana yang akan diinstal. Cukup gunakan Instal plugin yang disarankan pilihan untuk saat ini. Anda selalu dapat menambahkan atau menghapus plugin nanti.
Di halaman berikutnya, Anda harus membuat pengguna admin. Isi detail Anda dan buat kata sandi yang kuat untuk digunakan dengan akun baru Anda. Secara default, hanya pengguna yang login yang dapat mengakses server Jenkins. Pengguna anonim hanya akan melihat dialog login jika mereka mengunjungi situs web Anda. Satu-satunya alasan mengapa Anda dapat mengakses *situs demo saya jenkins.vhdlwhiz.com adalah saya telah membuat perubahan pada server. Saya menggunakan plugin Matrix Authorization Strategy untuk memberikan akses anonim ke beberapa tampilan.
* Pembaruan:Saya menghapus situs demo pada 13 Mei 2020
Ketika Jenkins selesai menginstal plugin, Anda akan melihat pesan “Jenkins siap!” pesan, seperti yang ditunjukkan pada gambar di atas. Klik tombol yang akan membawa Anda ke halaman ikhtisar kosong dari instalasi Jenkins baru Anda.
Hal pertama yang perlu Anda lakukan adalah menginstal banyak plugin. Jenkins memiliki pengelola plugin bawaan yang dapat Anda gunakan untuk memasang, memperbarui, dan menghapus ekstensi. Anda akan menemukan plugin yang dapat memenuhi sebagian besar kebutuhan Anda. Cukup gunakan fungsi pencarian di pengelola plugin ketika Anda perlu menambahkan fungsionalitas ke Jenkins.
Mari kita lanjutkan menginstal plugin yang saya gunakan saat menyiapkan contoh server Jenkins. Dari sidebar, pilih Kelola Jenkins->Kelola Plugin->Tersedia . Perhatikan bahwa tidak ada plugin yang terdaftar kecuali Anda memasukkan sesuatu di kolom pencarian. Setelah Anda mengetik, mereka akan muncul.
Plugin pertama yang saya rekomendasikan untuk diinstal bernama Blue Ocean. Plugin ini merupakan modernisasi alur kerja Jenkins serta antarmuka pengguna. Ini juga menyertakan banyak plugin berguna lainnya sehingga Anda tidak perlu menginstalnya satu per satu. Cari “blue ocean” di pengelola plugin dan pilih untuk instalasi, seperti yang ditunjukkan pada gambar di bawah.
Pada halaman kemajuan instalasi yang muncul setelah Anda mengklik instal, Anda memiliki opsi untuk memilih Restart Jenkins ketika instalasi selesai dan tidak ada pekerjaan yang berjalan . Jika Anda mencentang kotak di sebelahnya, Jenkins akan memulai ulang setelah instalasi plugin selesai. Cara lain untuk memulai ulang Jenkins adalah dengan masuk ke server melalui SSH dan menjalankan perintah berikut:
systemctl restart jenkins
Terlepas dari daftar panjang plugin lain yang dipasang oleh Blue Ocean, sekilas tidak ada perubahan nyata. Namun akan ada item menu baru di sidebar, seperti terlihat pada gambar di bawah. Ketika diklik, Anda akan dibawa ke GUI Blue Ocean, yang tampilannya sangat berbeda dari antarmuka Jenkins Normal. Cobalah!
Plugin berikutnya yang selalu saya instal murni untuk estetika. Plugin Green Balls tidak memerlukan konfigurasi apa pun. Cukup cari “bola hijau” di pengelola plugin dan instal seperti yang ditunjukkan pada gambar di bawah.
Secara default, Jenkins menggunakan bola warna biru di halaman ikhtisar untuk menunjukkan bahwa status pekerjaan berhasil. Alasannya ada hubungannya dengan penemu Jenkins adalah orang Jepang. Menariknya, di Jepang, warna biru dapat diganti dengan hijau untuk menunjukkan status OK. Lebih lanjut tentang itu di artikel ini, di mana Anda dapat mendengar penulis menjelaskan alasannya secara langsung.
Pengguna dari sebagian besar belahan dunia lain mungkin lebih menyukai bola status hijau. Hal ini mudah diperbaiki dengan plugin Green Balls, seperti yang ditunjukkan pada gambar di bawah.
Plugin selanjutnya yang saya install bernama Locale. Telusuri “lokal” di bawah Tersedia tab di manajer plugin. Instal plugin seperti yang ditunjukkan pada gambar di bawah ini.
Plugin ini memungkinkan Anda memaksa Jenkins untuk menggunakan bahasa yang sama di GUI untuk semua pengguna. Secara default, Jenkins menerjemahkan antarmuka pengguna ke bahasa yang digunakan browser web Anda. Saya orang Norwegia, tapi saya lebih suka Jenkins dalam bahasa Inggris. Terjemahannya agak tidak memadai. Selain itu, jauh lebih mudah mencari jawaban di Google dalam bahasa Inggris jika Anda perlu mengetahui cara melakukan sesuatu di Jenkins.
Tentu saja, sepenuhnya terserah Anda jika menginginkan plugin ini. Jika Anda menginstalnya, Anda perlu menavigasi ke Kelola Jenkins->Konfigurasi Sistem dan temukan bagian bernama Lokal . Kemudian, Anda perlu memasukkan “en_US” (atau bahasa apa pun yang Anda inginkan) dan centang kotak di bawah untuk memaksa bahasa ini ke semua pengguna, seperti yang ditunjukkan pada gambar di bawah. Jangan lupa untuk menggulir ke bagian bawah halaman dan klik Simpan .
Plugin terakhir yang Anda perlukan untuk mengkloning pengaturan saya adalah plugin Sidebar Link. Ini memungkinkan Anda menambahkan tautan khusus ke sidebar Jenkins. Kami akan menggunakannya nanti untuk menambahkan link ke rilis FPGA (bitfiles). Telusuri “sidebar” di pengelola plugin dan instal plugin, seperti yang ditunjukkan pada gambar di bawah.
Terlepas dari apakah repositori Anda bersifat publik atau pribadi, Anda perlu memberi Jenkins beberapa izin pada akun GitHub Anda. Setidaknya jika Anda ingin melakukannya dengan cara termudah, Anda harus membiarkan plugin Jenkins GitHub mengelola antarmuka dengan GitHub untuk Anda. Blue Ocean telah menginstal plugin GitHub. Berikut langkah-langkah untuk mengkonfigurasinya.
Pertama, Anda harus menginstal Git di sistem Anda. Plugin GitHub tidak sepenuhnya membutuhkannya, tetapi ketika Anda mulai bekerja dengan pekerjaan Jenkins, Anda harus memilikinya. Keluarkan perintah ini untuk menginstal Git di CentOS Linux:
Masuk ke GitHub, klik gambar profil Anda di sudut kanan atas, pilih pengaturan, dan buka Pengaturan Pengembang . Lalu, pilih Token akses pribadi dari menu sidebar kiri, atau klik link ini yang akan membawa Anda langsung ke sana.
Di sini, Anda perlu mengklik Buat token baru , seperti yang ditunjukkan pada gambar di bawah ini. GitHub akan menanyakan kata sandi Anda sekali lagi. Apa yang Anda lakukan sekarang pada dasarnya adalah membuat kata sandi khusus aplikasi yang baru. Itu lebih baik daripada membagikan kata sandi Anda yang sebenarnya karena Anda dapat mencabutnya, dan Anda dapat membatasi izin yang diberikan pada token tersebut. Itulah yang akan kami lakukan pada halaman yang terbuka.
Ketika Anda telah memasukkan kata sandi, Anda perlu memberi nama pada token tersebut. Nama itu hanya untukmu. Bisa apa saja, “Jenkins”, misalnya. Kemudian, Anda harus mengaktifkan setidaknya admin:org_hook , admin:repo_hook , dan repo izin, seperti yang ditunjukkan pada gambar di bawah ini. Anda dapat membiarkan semua kotak lainnya tidak dicentang.
Terakhir, ketika Anda mengklik Buat token , kode akses akan muncul. Anda perlu menyalinnya sebelum meninggalkan halaman itu karena tidak mungkin melihatnya lagi. Jika Anda lupa, hapus token dan buat ulang.
Jika Anda sudah menyalin token, buka Jenkins, pilih Kelola Jenkins->Konfigurasi Sistem , dan temukan bagian bernama GitHub , seperti yang ditunjukkan pada gambar di bawah ini. Dari menu tarik-turun, pilih Tambahkan Server GitHub->Server GitHub .
Di bagian Server GitHub baru yang muncul, centang kotak berlabel Kelola kait . Saat Anda melakukan ini, Jenkins akan menginstal webhook di GitHub untuk repo yang Anda pantau. Kita akan melihat nanti bahwa ini sangat berguna karena kita akan menggunakannya untuk memicu simulasi atau build di Jenkins ketika pengguna memasukkan kode ke repositori GitHub terkait.
Pilih Kredensial (Tambahkan)->Jenkins setelah Anda mencentang kotaknya, seperti terlihat pada gambar di bawah ini.
Di jendela yang terbuka, ubah Jenis tarik-turun ke Teks rahasia . Lalu, tempelkan token akses pribadi yang sebelumnya Anda buat di GitHub di Rahasia bidang. Tulis “GitHub” di kolom ID dan tekan Tambah .
Terakhir, saat Anda kembali ke menu konfigurasi utama, setelah menambahkan teks rahasia, pilih GitHub baru kunci dari Kredensial tidak bisa. Lalu, tekan Uji koneksi untuk memverifikasi bahwa Jenkins dapat berbicara dengan GitHub menggunakan token akses. Jika semuanya berjalan dengan baik, Anda akan melihat pesan seperti yang ditunjukkan pada gambar di bawah.
Pastikan untuk menggulir ke bagian bawah laman dan klik Simpan sebelum meninggalkan halaman konfigurasi.
Jika Anda mengalami masalah dan akhirnya menambahkan beberapa kredensial, Anda dapat menghapusnya dengan membuka Kelola Jenkins->Kelola Pengguna , dan klik nama pengguna Anda. Sekarang, di sidebar kiri, akan ada item menu bernama Kredensial . Dari sana, Anda dapat melihat dan mengedit semua kunci yang disimpan Jenkins.
Kami akan mengonfigurasi Jenkins untuk mengirim email otomatis ketika ada kerusakan pada kode Anda. Untuk mewujudkannya, kita perlu melakukan beberapa perubahan pada Kelola Jenkins->Konfigurasi Sistem tidak bisa.
Hal pertama yang harus Anda lakukan adalah memasukkan alamat asal yang akan digunakan Jenkins saat mengirim email otomatis. Temukan alamat email Admin Sistem pada halaman konfigurasi, dan masukkan alamat asal pengiriman Jenkins.
Sekadar catatan singkat:yang terbaik adalah memasukkan alamat yang diakhiri dengan nama domain Jenkins. Itu meminimalkan kemungkinan email masuk ke folder spam. Server Jenkins tidak memiliki izin untuk mengirim email atas nama domain lain, namun sebagian besar layanan email menerima alamat dari dengan domain yang sama dengan server pengirim. Baca lebih lanjut tentang itu di artikel Wikipedia ini. Pada gambar di bawah, saya memasukkan alamat asal yang diakhiri dengan domain yang sama dengan server Jenkins.
Selanjutnya, kita perlu memberi Jenkins cara untuk mengirim email. Cara paling mudah untuk melakukannya adalah dengan menginstal server SMTP (mail) di VPS. Anda dapat melakukannya dengan masuk dan mengeluarkan perintah berikut:
yum -y install sendmail systemctl enable sendmail systemctl restart sendmail
Setelah Anda menginstal sendmail , kembali ke konfigurasi sistem Jenkins dan masukkan “localhost” di server SMTP bidang, seperti yang ditunjukkan pada gambar di bawah ini.
Pada tahap ini, Anda juga dapat mencentang kotak untuk mengizinkan pengiriman ke pengguna yang tidak terdaftar. Itu berarti pengguna yang tidak memiliki akun pengguna Jenkins. Nanti, kami akan mengonfigurasi Jenkins untuk mengirim email ke siapa pun yang memasukkan kode yang salah ke GitHub. Jenkins akan mendapatkan alamat email pelakunya dari GitHub, namun itu hanya akan berfungsi jika orang tersebut memiliki akun Jenkins yang cocok, atau jika kami mencentang kotak ini.
Terakhir, Anda dapat menguji konfigurasinya, seperti yang ditunjukkan pada gambar di atas. Setelah Anda menekan Uji konfigurasi , pesan “Email berhasil terkirim” akan muncul, dan email akan masuk ke kotak masuk Anda. Periksa folder spam Anda jika Anda tidak menerima email dalam waktu lima menit.
Saya menggunakan Xilinx Vivado untuk mensimulasikan, mengkompilasi, dan mengimplementasikan kode dalam proyek contoh ini. Perangkat targetnya adalah Xilinx Zynq-7000 FPGA di papan pengembangan ZebBoard. Di bagian ini, saya akan menunjukkan cara menginstal Vivado di VPS menggunakan lisensi WebPACK gratis.
Langkah pertama adalah mendownload Xilinx Unified Installer:Linux Self Extracting Web Installer, seperti terlihat pada gambar di bawah ini. Anda harus masuk atau membuat akun Xilinx baru untuk mengunduh penginstal.
Ketika pengunduhan selesai, Anda harus menyalinnya dari komputer desktop Anda ke server Jenkins. Jika Anda memiliki akses ke shell Linux di desktop Anda, saya sarankan menggunakan salinan file aman seperti pada perintah berikut:
Sebelum Anda dapat menjalankan penginstal, Anda perlu menginstal beberapa paket untuk memenuhi ketergantungan Vivado. Jalankan perintah berikut untuk melakukannya:
yum -y install tar yum -y install java-11-openjdk-devel yum -y install ncurses-compat-libs yum -y install gcc
Kemudian, jalankan installer Xilinx Unified seperti ini:
./Xilinx_Unified_2019.2_1106_2127_Lin64.bin --keep --noexec --target Xil_installer
File .bin akan membongkar file instalasi ke direktori baru bernama Xil_installer . Jika Anda mendapatkan kesalahan seperti di bawah ini, itu karena Anda belum menginstal tar .
Verifying archive integrity... All good. Uncompressing Xilinx InstallerExtraction failed. Terminated
Penginstal Xilinx Unified dapat menginstal banyak alat Xilinx yang berbeda di sistem Anda. Oleh karena itu, kita harus menjalankan xsetup file di Xil_installer direktori untuk menentukan perangkat lunak mana yang kami minati:
cd Xil_installer/ ./xsetup -b ConfigGen
xsetup skrip meminta Anda alat mana yang ingin Anda miliki. Masukkan “2” untuk Vivado , lalu “1” untuk Vivado HL WebPACK , seperti yang ditunjukkan pada daftar di bawah.
Select a Product from the list: 1. Vitis 2. Vivado 3. On-Premises Install for Cloud Deployments 4. BootGen 5. Lab Edition 6. Hardware Server 7. Documentation Navigator (Standalone) Please choose: 2 Select an Edition from the list: 1. Vivado HL WebPACK 2. Vivado HL Design Edition 3. Vivado HL System Edition Please choose: 1
Untuk menginstal edisi Xilinx WebPACK, Anda harus masuk ke akun Xilinx Anda selama instalasi. Di komputer desktop, GUI penginstal memandu Anda melalui proses ini, namun di server, tidak ada GUI, jadi kami harus mengautentikasi dengan menggunakan xsetup naskah. Jalankan perintah berikut untuk menghasilkan token autentikasi:
Saya harus menjalankan perintah beberapa kali sebelum berhasil. Pada awalnya, skrip berhenti dengan kesalahan “Koneksi internet divalidasi, dapat terhubung ke internet.” Namun, setelah beberapa kali mencoba, saya berhasil, dan saya dapat masuk. Skrip akan meminta ID pengguna dan kata sandi Anda. Itu adalah email dan sandi yang Anda gunakan untuk mengunduh penginstal dari xilinx.com.
Terakhir, Anda siap menginstal Vivado dalam mode batch. Saat memanggil skrip setup, Anda harus menentukan file konfigurasi instalasi agar xsetup tahu alat mana yang harus diunduh. File konfigurasi ada di .Xilinx folder di direktori home pengguna root. Jalankan perintah berikut untuk memulai instalasi menggunakan file konfigurasi:
./xsetup -a XilinxEULA,3rdPartyEULA,WebTalkTerms \ -b Install -c ~/.Xilinx/install_config.txt
Proses instalasi akan memakan waktu lama untuk diselesaikan. Instalasi Vivado menggunakan ruang 24 GB. Semua itu sekarang diunduh dari server Xilinx yang relatif lambat. Bagi saya, pengunduhannya hanya memakan waktu dua jam lebih.
Setelah instalasi selesai, Anda harus menguji apakah Vivado berhasil dijalankan dalam mode batch. Xilinx provides a shell script that sets up the environment for you. Before you can run Vivado, you need to use the source command to load the content of the script into your active shell:
source /tools/Xilinx/Vivado/2019.2/settings64.sh
Then, you are ready to run Vivado. But there’s no GUI environment installed on your server, so we have to start it in batch mode by using this command:
If Vivado starts and exists immediately without printing any errors, it’s an indication that Vivado has everything it needs, and you are ready to go. Note that if you are getting the error listed below, it’s because you haven’t installed the ncurses-compat-libs package, as we talked about at the start of this section.
application-specific initialization failed: couldn't load file "librdi_commontasks.so": libtinfo.so.5: cannot open shared object file: No such file or directory
To prepare Jenkins for Vivado, we need to make some changes to the general settings. Head to Manage Jenkins->Configure System and check that all the default settings make sense for you.
As I mentioned earlier, Vivado uses a lot of RAM. The resource usage depends on your target FPGA, and you can get an indication of how much you need from the Xilinx Memory Recommendations page. Therefore, I recommend that you change the default number of parallel jobs that can run from 2 to 1. Unless you allocated vast RAM resources on your VPS, you probably want to set # of executors to 1, as shown in the image below.
Instead of defining the environment variables in every Jenkins job, we will specify the PATH globally for all jobs. That makes it easier for you to swap to a newer version of Vivado in the future. Then you can refer to the ‘vivado’ executable in your scripts, and it will always point to the latest version, or whichever you decide.
Scroll to the Global properties section and check Environment variables . Click Add to get a new entry. Make sure to include the standard Linux PATH juga. I used “PATH=/tools/Xilinx/Vivado/2019.2/bin:/sbin:/usr/sbin:/bin:/usr/bin”, as shown in the image below.
Don’t forget to scroll to the bottom of the page and click Save .
I chose to manage the Vivado projects in GUI mode. For each repository, I created a new project from within the regular Vivado GUI, adding source files, setting libraries, and all of that. However, the .xpr project files are binary and depend on a lot of other temporary files in the project directory.
Binary files are not suitable for SCMs like Git. Fortunately, Xilinx has thought of this and written a guideline (XAPP1165) for how to use Vivado with version control systems. What we do is to use the write_project_tcl command in Vivado to export the entire project into a Tcl script. The script contains human-readable Tcl code suitable for Git.
I’ve organized all of the Git repos so that all files that belong to the Vivado projects are in a subfolder named “vivado”, while the VHDL source files are in the parent directory. Check out the demo packages project on my GitHub to see what I mean. For each repo, we will put the Vivado Tcl scripts in the vivado folder. You will also find the create_vivado_proj.tcl file, which is the human-readable version of the Vivado project.
To create the create_vivado_proj.tcl file, start by setting up the Vivado project as you wish in the Vivado GUI. Make sure that the Vivado project resides within a vivado subfolder. When you’re happy with the project, export it by entering the following commands in the Vivado Tcl console:
cd [get_property DIRECTORY [current_project]] write_project_tcl -force -target_proj_dir . create_vivado_proj
Add the create_vivado_proj.tcl file to Git, and set up the gitignore to ignore the rest of the Vivado project. Here’s the content of my .gitignore file which ignores everything but Tcl scripts in the vivado folder:
It’s a good idea to test the Vivado project manually on the VPS before you start creating Jenkins jobs. By default, the daemon runs from a user account named jenkins on the Linux server. Therefore, you should test the Vivado project using the jenkins user.
Make sure that you have Git installed on the Linux server before you start this experiment. Run this command to install Git after logging in as root:
You can’t log in to the jenkins user directly, but you can change to it from the root user like this:
If you now run a pwd command, you will see that you are at /var/lib/jenkins :
[jenkins@jenkins ~]$ pwd /var/lib/jenkins
That’s because this isn’t a regular user account that has the home directory under /home , as is the norm on Linux systems. It’s only for running the Jenkins daemon, but we can log in to perform a manual walkthrough of the build process in the Jenkins environment.
The home folder is full of all the dynamic data like logs, user settings, and plugins that you have downloaded. When we later start running jobs in the Jenkins GUI, they will appear in the jobs folder.
Let’s go to the jobs folder to perform our experiment:
cd /var/lib/jenkins/jobs/
You can clone your Git repository directly into the jobs folder. Your Git repo has to be accessible without using a password. Either because it’s public, or because you have set up passwordless login as described on the GitHub help pages.
If you don’t have a Git repository with the Vivado project ready, feel free to clone one of my repos like this:
git clone https://github.com/jonasjj/Jenkins-demo-packages
Then, cd into the new directory of the Git repository, and further into the vivado folder:
cd Jenkins-demo-packages/vivado/
If you downloaded my example, you would find two Tcl files:create_vivado_proj.tcl and check_syntax.tcl . The first one is the Vivado project converted to a Tcl file, and the second one is a script that we haven’t talked about yet. It’s for checking the syntax of VHDL files in the Vivado project.
Before we can run any Vivado command, we need to set the PATH environment variable in the current shell. In Jenkins, we solved this by using Global properties , but now we are not coming through Jenkins, so we have to source the setup script from Xilinx like this:
source /tools/Xilinx/Vivado/2019.2/settings64.sh
Now that the vivado executable is in our path, let’s start by recreating the project. This is the command for doing that when running Vivado in batch mode:
vivado -mode batch -source create_vivado_proj.tcl
After you hit Enter, you should see a whole lot of Tcl code echoed to the console. It’s the code for recreating the Vivado project that’s executing. If you didn’t see any obvious errors, type the command “echo $?” in the terminal before you do anything else. The output should be 0 if everything went well, as we can see from the listing below.
INFO: [Common 17-206] Exiting Vivado at Sun Apr 19 18:32:48 2020... [jenkins@jenkins vivado]$ echo $? 0
The “echo $?” command shows you the exit status from the previous command that you executed in Linux. An exit status of 0 means that everything is OK, no error. Any other exit status than 0 is an indication of error. Those are old Unix conventions that you can read more about here. Anyway, the exit status is important for Jenkins because that’s how it decides if a job stage is a success or a failure.
If you now do a directory listing, you will see that Vivado has recreated the project’s binary files:
[jenkins@jenkins vivado]# ls -la total 72 drwxrwxr-x. 6 jenkins jenkins 4096 Apr 19 18:32 . drwxrwxr-x. 4 jenkins jenkins 4096 Apr 19 18:18 .. -rw-rw-r--. 1 jenkins jenkins 217 Apr 19 18:18 check_syntax.tcl -rw-rw-r--. 1 jenkins jenkins 23375 Apr 19 18:18 create_vivado_proj.tcl drwxrwxr-x. 3 jenkins jenkins 16 Apr 19 18:32 packages.cache drwxrwxr-x. 2 jenkins jenkins 26 Apr 19 18:32 packages.hw drwxrwxr-x. 2 jenkins jenkins 6 Apr 19 18:32 packages.ip_user_files -rw-rw-r--. 1 jenkins jenkins 9314 Apr 19 18:32 packages.xpr -rw-rw-r--. 1 jenkins jenkins 638 Apr 19 18:32 vivado.jou -rw-rw-r--. 1 jenkins jenkins 20153 Apr 19 18:32 vivado.log drwxrwxr-x. 2 jenkins jenkins 6 Apr 19 18:32 .Xil
Let’s try another experiment with running Tcl scripts in Vivado batch mode. Create a one-liner Tcl script by using the following command:
Now, run the script in Vivado batch mode:
vivado -mode batch -source test.tcl
After Vivado closes, check the exit code once more using the “echo $?” command:
[jenkins@jenkins vivado]# echo $? 1
It’s 1, which means exit failure in Unix. If you change the content of the test.tcl script to “exit 0”, and run Vivado once again, you will see that the exit status is now 0, indicating success. Try it!
The exit keyword is standard Tcl. We are going to use it as the interface between Vivado and Jenkins. Jenkins runs whatever Tcl script we create in Vivado, and looks at the exit status to determine if it shall mark the job stage as success or failure.
Remember to delete our little test project from the jobs folder when you are happy with the experiment:
cd /var/lib/jenkins/jobs/ [jenkins@jenkins jobs]# rm -rf Jenkins-demo-packages
This Tcl script runs a syntax check of the VHDL files in the project. If you are going to simulate or implement the code, you won’t need this script because any syntax errors will break the compilation. But for my packages project, it doesn’t make any sense to create a testbench for it. The files just contain constant and types declarations. I still want to catch any coding errors pushed to this repo, and that’s where the syntax check comes in handy.
In the script that is listed below, we start by opening the project file. Then, we call the Vivado check_syntax command while telling it to save the output to a variable called msg . After the check has completed, we look at the output message to see if there were any errors reported. If check_syntax reported anything at all, we set the exit status to 1 (failure). If there were no errors, we exit 0 (success).
check_syntax.tcl:
# Check for syntax errors
# Return exit code 1 on error, else 0
open_proj packages.xpr
set msg [check_syntax -fileset sim_1 -return_string]
set ret_val 0
if {$msg != ""} {
set ret_val 1
}
puts $msg
exit $ret_val
Vivado supports all of the standard Tcl keywords, and there are also a lot of built-in commands like check_syntax. I recommend taking a look at these two Xilinx documents that cover the Tcl scripting capabilities in great detail:
Vivado Design Suite Tcl Command Reference Guide (UG835)
Vivado Design Suite User Guide Using Tcl Scripting (UG894)
The next script that I created is for running the testbench in batch mode. For this to work, you have to configure the simulation sets in the Vivado GUI before you export the project to Tcl. Go ahead and recreate one of the simulation projects on your desktop computer using the create_vivado_proj.tcl script to see how I set it up beforehand. You can open the reconstructed projects in the Vivado GUI.
As you can see from the listing below, I start by opening the project. Then, I set the name of the simulation fileset to a variable (usually sim_1 ). After we launch the simulation, we also have to close it. Otherwise, the status of the simulation won’t get written to the log files.
run_simulation.tcl:
open_proj seg7.xpr set sim_fileset sim_1 launch_simulation -simset [get_filesets $sim_fileset] close_sim # Look for assertion failures in the simulation log set log_file [glob *sim/$sim_fileset/behav/xsim/simulate.log] set fp [open $log_file] set file_data [read $fp] exit [regex "Failure:" $file_data]
Now, I struggled to find a good way of getting the simulation status. My VHDL testbenches terminate on a VHDL finish keyword on success. Errors will result in a VHDL assertion failure. There’s no obvious way to find out why the simulator stopped by using Tcl commands in Vivado.
Fortunately, Tcl is a powerful scripting language. My workaround is to open the simulation log and look for the string “Failure:”, which indicates a VHDL assertion failure. Finally, we exit 1 if the word is in the log, or 0 if it isn’t.
In the Tcl script for synthesizing in Vivado batch mode, we start by opening the project file. Then, We assign the run name to a variable. You must have added the design files to the Vivado project before you exported it to Tcl. If you didn’t change the name of the synthesis run in the GUI, it’s will probably be “synth_1”.
You should set the CPU count variable to the number of logical processors that your server has. This number controls the degree of multithreading that Vivado uses. I opted for the VPS with 4 CPUs on UpCloud, and therefore set the CPU count to 4.
run_synthesis.tcl :
open_proj seg7.xpr
set run_name synth_1
set cpu_count 4
reset_runs $run_name
launch_runs $run_name -jobs $cpu_count
wait_on_run $run_name
set status [get_property STATUS [get_runs $run_name]]
if {$status != "synth_design Complete!"} {
exit 1
}
exit 0
The launch_runs command is non-blocking, meaning that it will complete before the actual synthesis. If we try to read the status right after calling launch_run , it will be “Running”. To pause the script until the synthesis completes, we call the wait_on_run command.
Finally, we get the run status and exit 0 or 1, depending on the status message.
The script for running Place and Route (PAR) in Vivado batch mode is similar to the synthesis script. The difference is that the run name is now “impl_1”, and that we are looking for another success message.
run_implementation.tcl :
open_proj seg7.xpr
set run_name impl_1
set cpu_count 4
reset_runs $run_name
launch_runs $run_name -jobs $cpu_count
wait_on_run $run_name
set status [get_property STATUS [get_runs $run_name]]
if {$status != "route_design Complete!"} {
exit 1
}
exit 0
Finally, after if the implementation completes successfully, we can generate a bitstream for programming the FPGA. The script is similar to the previous one, but the launch_runs command is slightly different. And of course, we are looking or a different status in the end.
generate_bitstream.tcl :
open_proj seg7.xpr
set run_name impl_1
set cpu_count 4
launch_runs $run_name -to_step write_bitstream -jobs $cpu_count
wait_on_run $run_name
set status [get_property STATUS [get_runs $run_name]]
if {$status != "write_bitstream Complete!"} {
exit 1
}
exit 0
A job in Jenkins refers to a set of grouped software tasks. Jenkins displays jobs and their current status as items listed on the overview page. You can start jobs manually from the web interface, or they can be triggered automatically, for example, when someone pushes code to a repo, or as a result of another job completing. We will do both.
Jenkins offers several ways of managing jobs. The traditional method is the Freestyle project , where you specify every action from within the Jenkins web GUI. The more modern way of managing Jenkins jobs is to use a pipeline script that stores all of the information about the execution flow. The pipeline scripts have the benefit that you can add them to your SCM.
To create a new pipeline script, select New item from the Jenkins sidebar. In the dialog that opens, select the Pipeline option and click OK, as shown in the image below.
The first thing we have to do in the job configuration is to add the GitHub repository that contains the source code. In this example, I am using the packages repo, but the procedure is the same for all the other jobs and repos. Check the GitHub project box and enter the address in the Project url field that appears, as shown in the image below.
After that, we can set up the build triggers for this job. I want this job to start when someone pushes code to the GitHub repo. To do that, we check the box that says GitHub hook trigger for GITScm polling , as shown in the image below. Note that this will only work if you have checked the Manage hooks box in the global settings, as we did earlier.
At the bottom of the job configuration page is the Pipeline section. Here, you have to option to enter the pipeline script directly into the config page. But we want to version control the pipeline script. Therefore, we chose the Pipeline script from SCM option. Make sure that Git is selected, as shown in the image below.
Paste in the URL of your GitHub repository, and select your credentials if it’s a private repo. Ours is public, so we will leave the credentials blank. We will also go with the default master branch selection.
Finally, we have to select the path to the Jenkins script within the Git repository. I have created a file named Jenkinsfile at the root of each repo. Don’t forget to click Save before you leave the page.
Pipeline scripts follow the same syntax rules as the Apache Groovy programming language, which I must admit I had never heard of before. Nevertheless, you won’t have a hard time understanding pipeline scripts if you’ve done any kind of modern programming. At first glance, it looks like a JSON schema without the commas separating the data items.
The scripts are quite versatile, and there are many options for things like executing stages in parallel or running tasks on multiple Jenkins servers. I suggest that you take a look at the official Jenkins pipeline documentation if you want to dig deeper into the matter.
Fortunately, you don’t need to know everything about them to benefit from pipeline scripts. We will use the format below as a template for all of your scripts. We will add as many stages as we need to split the job into logical steps.
pipeline {
agent any
stages {
stage('Stage name 1') {
steps {
// Command 1
// Command 2
// Etc.
}
}
stage('Stage name 2') {
steps {
// Command 1
// Command 2
// Etc.
}
}
}
post {
failure {
emailext attachLog: true,
body: '''Project name: $PROJECT_NAME
Build number: $BUILD_NUMBER
Build Status: $BUILD_STATUS
Build URL: $BUILD_URL''',
recipientProviders: [culprits()],
subject: 'Project \'$PROJECT_NAME\' is broken'
}
}
}
If somebody pushes faulty code to the repo, we want the culprit to receive an automated email with information about the failed job. To do that, we use a failure section within a post section. This part of the script will only execute if any of the stages fail. Then, the job will stop. Jenkins won’t go to the next stage if one fails. Instead, it will jump into the failur e section. Jenkins then lifts the email addresses from the latest Git commits and sends them an email with a link to the broken build.
The only repo in our design that doesn’t have a testbench is the packages repo—instead, we user our check_syntax.tcl script to verify that the code is at least valid VHDL.
In the first step of our pipeline script, we call deleteDir() . That’s one of the basic commands available in Jenkins pipeline scripts. It cleans the working directory by removing any leftover from previous builds.
On the next line, we call git . Note that this is not the git Linux command, but a command referencing the git Jenkins plugin. We tell it to clone the repository into the workspace.
Finally, on the third line of the Create project stage, we use the sh keyword to call a Linux shell command. Here, we change to the vivado directory and run the create_vivado_proj.tcl script in Vivado batch mode to recreate the Vivado project.
Jenkinsfile:
pipeline {
agent any
stages {
stage('Create project') {
steps {
deleteDir() // clean up workspace
git 'https://github.com/jonasjj/Jenkins-demo-packages'
sh 'cd vivado && vivado -mode batch -source create_vivado_proj.tcl'
}
}
stage('Check VHDL syntax') {
steps {
sh 'cd vivado && vivado -mode batch -source check_syntax.tcl'
}
}
}
post {
failure {
emailext attachLog: true,
body: '''Project name: $PROJECT_NAME
Build number: $BUILD_NUMBER
Build Status: $BUILD_STATUS
Build URL: $BUILD_URL''',
recipientProviders: [culprits()],
subject: 'Project \'$PROJECT_NAME\' is broken'
}
}
}
In the second stage, the one named Check VHDL syntax , the Vivado project already exists, so we can jump to running our Tcl script. We use the shell command again to run the check_syntax.tcl file, which will exit 0 on success, or 1 on error, causing Jenkins to mark the build as a failure.
For all other jobs than the packages repo, the git one-liner command won’t work for checking out the code from GitHub. The problem is that these repos have dependencies in the form of submodules. The submodules reference other Git repositories, which the simple git command doesn’t pull by default. But that’s OK; we can fix the issue by using the more versatile checkout call, also well-documented on the Git plugin page.
Jenkinsfile;
pipeline {
agent any
stages {
stage('Create project') {
steps {
deleteDir() // clean up workspace
checkout([$class: 'GitSCM', branches: [[name: '*/master']],
doGenerateSubmoduleConfigurations: false,
extensions: [[$class: 'SubmoduleOption',
disableSubmodules: false,
parentCredentials: false,
recursiveSubmodules: true,
reference: '',
trackingSubmodules: true]],
submoduleCfg: [],
userRemoteConfigs: [[
url: 'https://github.com/jonasjj/Jenkins-demo-bcd_encoder']]])
sh 'cd vivado && vivado -mode batch -source create_vivado_proj.tcl'
}
}
stage('Run simulation') {
steps {
sh 'cd vivado && vivado -mode batch -source run_simulation.tcl'
}
}
}
post {
failure {
emailext attachLog: true,
body: '''Project name: $PROJECT_NAME
Build number: $BUILD_NUMBER
Build Status: $BUILD_STATUS
Build URL: $BUILD_URL''',
recipientProviders: [culprits()],
subject: 'Project \'$PROJECT_NAME\' is broken'
}
}
}
Finally, we run the run_simulation.tcl script in Vivado in the next stage.
The above listing shows the script used in the bcd_encoder repo. Identical scripts, only with different repo URLs, are used for the counter, digit_selector, output_mux, reset, and seg7_encoder repos as well.
The seg7 repo contains the top module for our FPGA project. It pulls in all of the other repos as submodules. The pipeline script is similar to the one used for the simulation-only jobs, but with four added stages:Run simulation , Run implementation , Generate bitstream , and Release bitfile .
The first two stages create the project and run the simulation. I have already covered how they work in the previous sections of this article. The next three stages work the same way as the simulation stage, but with the Tcl script replaced with the ones that are relevant for the task.
Jenkinsfile:
pipeline {
agent any
stages {
stage('Create project') {
steps {
deleteDir() // clean up workspace
checkout([$class: 'GitSCM', branches: [[name: '*/master']],
doGenerateSubmoduleConfigurations: false,
extensions: [[$class: 'SubmoduleOption',
disableSubmodules: false,
parentCredentials: false,
recursiveSubmodules: true,
reference: '',
trackingSubmodules: true]],
submoduleCfg: [],
userRemoteConfigs: [[
url: 'https://github.com/jonasjj/Jenkins-demo-seg7']]])
sh 'cd vivado && vivado -mode batch -source create_vivado_proj.tcl'
}
}
stage('Run simulation') {
steps {
sh 'cd vivado && vivado -mode batch -source run_simulation.tcl'
}
}
stage('Run synthesis') {
steps {
sh 'cd vivado && vivado -mode batch -source run_synthesis.tcl'
}
}
stage('Run implementation') {
steps {
sh 'cd vivado && vivado -mode batch -source run_implementation.tcl'
}
}
stage('Generate bitstream') {
steps {
sh 'cd vivado && vivado -mode batch -source generate_bitstream.tcl'
}
}
stage('Release bitfile') {
steps {
sh '''
PROJ_NAME=seg7
RELEASE_DIR=/usr/share/nginx/html/releases/
BASE_NAME=$PROJ_NAME-`date +"%Y-%m-%d-%H-%H:%M"`
BITFILE=$BASE_NAME.bit
INFOFILE=$BASE_NAME.txt
git log -n 1 --pretty=format:"%H" >> $INFOFILE
echo -n " $PROJ_NAME " >> $INFOFILE
git describe --all >> $INFOFILE
echo "" >> $INFOFILE
echo "Submodules:" >> $INFOFILE
git submodule status >> $INFOFILE
cp $INFOFILE $RELEASE_DIR
cp vivado/seg7.runs/impl_1/top.bit $RELEASE_DIR/$BITFILE
'''
}
}
}
post {
failure {
emailext attachLog: true,
body: '''Project name: $PROJECT_NAME
Build number: $BUILD_NUMBER
Build Status: $BUILD_STATUS
Build URL: $BUILD_URL''',
recipientProviders: [culprits()],
subject: 'Project \'$PROJECT_NAME\' is broken'
}
}
}
The final stage of the implementation job is named Release bitfile . It contains a shell script that copies the newly generated FPGA programming file to a release folder. The shell command renames the file to include the name of the project and a timestamp.
To maintain traceability, we also generate a text file that contains the Git hash of the main repo (seg7 ) and all of the submodules. When working with Git submodules, it’s not enough to store the hash of the main repo. To generate a hash for the main repo that includes changes in all submodules, we would have to commit the main repo after pulling and updating all submodules. We don’t want to do that automatically from Jenkins.
Note that implementing the FPGA for every single push, like I am doing in the example, is probably not what you want for a real-life Jenkins project. It can take hours to build a large-scale FPGA project, and that wouldn’t work when you have a team of developers pushing multiple times per day. Instead of building after each push to the repo, you can configure Jenkins to route the FPGA only once a day. For example, at midnight, as shown by the screenshot below from the job configuration page.
Our example project consists of several Git repositories, but they are all tied together as Git submodules. Except for packages, all the other repos depend on at least one other repository. Most depend on the packages repository. Have a look at the dependency graph that I presented earlier in this article to see how it all fits together.
Therefore, we should trigger jobs not only by pushes to the repo in question but also after any of the submodules are touched. We can achieve this in Jenkins by visiting every job and setting the Build after other projects are built option accordingly.
The image below shows the trigger for the bcd_encoder project. It will start after the packages repo, which it depends on, completes a build successfully.
The top module depends on all other repos. I have added them as watch projects in a comma-separated list, as shown in the image below. Note that you may not want to do this for the FPGA implementation job if it takes a long time to route, as I mentioned in the previous section.
Since we already have a web server running, we can use if for serving the release files over HTTP. I want all new bitfiles to appear on the URL jenkins.vhdlwhiz.com/releases . Let’s see how we can use Nginx for this.
Our implementation job already copies new bitfiles to a directory on the Nginx HTML root, but we haven’t created it yet. Create the release dir and give the Jenkins user write permissions by issuing the following commands:
mkdir /usr/share/nginx/html/releases/ chown jenkins.root /usr/share/nginx/html/releases/
Then we have to make a change to the /etc/nginx/nginx.conf file. Find the server section in the config file with a name equal to your domain. Add the following location section inside of it, directly below the root (‘/’) location section:
location ^~ /releases {
alias /usr/share/nginx/html/releases/;
autoindex on;
}
Finally, after you have saved the file, test the configuration file, and reload the Nginx server:
nginx -t systemctl reload nginx
If everything worked, you should be able to list the content of the release directory, as shown in the screenshot below from Google Chrome.
To tie the Jenkins web interface to the release dir, I want to create a link to if from the Jenkins sidebar. We have already installed the Sidebar Link plugin that enables custom links in the sidebar.
The next step is to go to Manage Jenkins->Configure System and scroll down to the Additional Sidebar Links section. Here, we can specify the name and URL of the new link, as shown in the image below. The link icon field is optional. I reused one of the icons that came with the Jenkins server.
After completing the previous step, you should now have a custom link to the bitfile releases in the sidebar, complete with a nice-looking folder icon, as you can see from the image below.
Jenkins can be a valuable tool also for FPGA teams. Automating tasks can save your company time and improve the quality of your code. By using automatic build triggers and automated job pipelines, fewer coding errors will go unnoticed.
As we have seen from the example project presented in this article, Jenkins can implement a complete suite of regression tests for your VHDL code. It shows the current health of your project in a pleasant graphical web interface, suitable for even the most VHDL-illiterate project manager.
If you wish to try out Jenkins for FPGA development, I recommend following the steps in this article on an UpCloud VPS instance. I thoroughly researched all VPS providers a few years ago before moving VHDLwhiz to a VPS. I found that UpCloud was the fastest and best alternative. I’m still 100% pleased with the service.
If you decide to open an account on UpCloud, I kindly ask that you use my referral link or code:NV78V6 . Not only do you support VHDLwhiz, but you also get $25 of credit on UpCloud when using the promo code.
VHDL
Haas CNC Mill G Codes (Fungsi Persiapan) Ini adalah daftar kode-g pabrik cnc untuk mesin penggilingan cnc Haas. Tentu saja kode g pemrograman pabrik cnc adalah tulang punggung ketika pemrogram cnc sedang dalam tugas mereka untuk memprogram cnc mill. Artikel Terkait: G-Codes Bubut CNC Haas Kode-M
Apa itu Warisan dalam C#? Warisan adalah konsep penting dari C#. Warisan adalah konsep di mana Anda mendefinisikan kelas induk dan kelas anak. Kelas anak mewarisi metode dan properti dari kelas induk, tetapi pada saat yang sama, mereka juga dapat mengubah perilaku metode jika diperlukan. Kelas anak
Abstrak Sintesis terkontrol dari berbagai nanokristal ZnO dicapai melalui proses hidrotermal yang sederhana dan hemat biaya. Evolusi morfologi struktur nano ZnO dipantau dengan baik dengan menyetel parameter pertumbuhan hidrotermal, seperti konsentrasi larutan, suhu reaksi, dan surfaktan. Nanocryst
Sarah Firisen adalah direktur senior pengembangan bisnis untuk Aliansi PwC di UiPath . Di dunia yang cepat berubah saat ini, setiap perusahaan memahami pentingnya inovasi. Tetapi mantra inovasi, “gagal cepat dan sering gagal”, adalah mantra yang dapat membuat mulas perusahaan. Bagaimana perusahaan