Dukungan untuk wildcard dan ekspresi bersyarat dalam file pipeline YAML

Dalam sprint ini, kami menyertakan dukungan untuk wildcard dan ekspresi bersyarat pada file alur YAML. Selain itu, kami telah membuat beberapa pembaruan pada gambar yang dihosting Azure Pipelines.

Lihat deskripsi fitur berikut untuk detailnya.

Azure Pipelines (Alat otomatisasi alur kerja pengembangan perangkat lunak dari Microsoft)

Azure Repos

Azure Pipelines (Alat otomatisasi alur kerja pengembangan perangkat lunak dari Microsoft)

Ekspresi bersyarjana YAML baru

Menulis ekspresi bersyarat dalam file YAML menjadi lebih mudah dengan penggunaan ekspresi ${{ else }} dan ${{ elseif }}. Di bawah ini adalah contoh cara menggunakan ekspresi ini dalam file alur YAML.

steps:
- script: tool
  env:
    ${{ if parameters.debug }}:
      TOOL_DEBUG: true
      TOOL_DEBUG_DIR: _dbg
    ${{ else }}:
      TOOL_DEBUG: false
      TOOL_DEBUG_DIR: _dbg

variables:
  ${{ if eq(parameters.os, 'win') }}:
    testsFolder: windows
  ${{ elseif eq(parameters.os, 'linux') }}:
    testsFolder: linux
  ${{ else }}:
    testsFolder: mac

Dukungan untuk wildcard dalam filter jalur

Wildcard dapat digunakan saat menentukan cabang inklusi dan pengecualian untuk pemicu CI atau PR dalam file YAML pipeline. Namun, filter tersebut tidak dapat digunakan saat menentukan filter jalur. Misalnya, Anda tidak dapat menyertakan semua jalur yang cocok dengan src/app/**/myapp*. Ini telah dinyatakan sebagai ketidaknyamanan oleh beberapa pelanggan. Pembaruan ini mengisi kesenjangan ini. Sekarang, Anda dapat menggunakan karakter wild card (**, *, atau ?) saat menentukan filter jalur.

Dukungan untuk beberapa status di Bitbucket

Azure Pipelines terintegrasi dengan repositori Bitbucket dan mendukung pemicu CI dan PR. Anda dapat menyiapkan beberapa alur dari satu repositori Bitbucket. Namun, ketika alur ini selesai, Anda hanya dapat melihat satu status di Bitbucket. Kami mendengar umpan balik dari Komunitas Pengembang yang meminta untuk melihat status setiap alur secara terpisah di Bitbucket. Dengan pembaruan ini, kami memperbarui panggilan API kami ke Bitbucket dan meneruskan informasi tambahan tentang nama alur.

Build statusBuild statusstatus Build

Izinkan kontributor untuk melewati pencarian komentar PR sebelum membangun validasi

Saat menggunakan Azure Pipelines dengan repositori GitHub, kami sarankan Anda tidak secara otomatis menjalankan alur validasi PR untuk kontribusi yang diterima dari repositori fork. Praktik terbaik adalah terlebih dahulu meminta salah satu kolaborator repositori meninjau perubahan lalu menambahkan komentar ke PR untuk memicu alur. Anda dapat mengonfigurasi pengaturan ini dengan memilih menu Pemicu (untuk alur YAML) atau tab Pemicu (untuk alur build klasik) di editor web alur. Alih-alih mengharuskan setiap PR dari fork untuk terlebih dahulu ditinjau oleh anggota tim, Anda juga dapat memberlakukan kebijakan ini hanya pada kontribusi yang berasal dari anggota non-tim.

Dengan pembaruan ini, kami mengizinkan Anda untuk melompati mencari komentar PR dari kontribusi yang diterima oleh kontributor apa pun. Sebagai anggota non-tim, saat Anda membuat fork dan membuat PR ke upstream, Anda tidak dianggap sebagai kontributor ke repositori upstram hingga PR Anda digabungkan. Setelah PR Anda digabungkan, Anda akan dianggap sebagai kontributor. Dengan memilih opsi baru yang ditampilkan di bawah ini, ketika anggota non-tim mengirimkan PR dari fork untuk pertama kali, seseorang di tim Anda harus meninjau PR tersebut dan menambahkan komentar untuk memicu pipeline. Tetapi, setelah PR digabungkan, kontribusi lebih lanjut yang dibuat oleh anggota non-tim tersebut akan langsung memicu alur tanpa menunggu komentar PR.

Mewajibkan komentar anggota tim sebelum membuat permintaan pull

Windows Server 2022 dengan Visual Studio 2022 sekarang tersedia di agen yang dihosting Microsoft (pratinjau)

Pratinjau Windows Server 2022 dan Visual Studio Enterprise 2022 sekarang tersedia dalam pratinjau pada agen yang dihosting Microsoft. Anda dapat menggunakannya dengan merujuk windows-2022 sebagai gambar dalam pipeline Anda.

pool:
  vmImage: 'windows-2022'

steps:
- task: NuGetToolInstaller@1
- task: NuGetCommand@2
  inputs:
    restoreSolution: '**/*.sln'
- task: VSBuild@1 # Visual Studio 2022 build
  inputs:
    solution: '**/*.sln'
    msbuildArgs: '/p:DeployOnBuild=true /p:WebPublishMethod=Package /p:PackageAsSingleFile=true /p:SkipInvalidConfigurations=true /p:DesktopBuildPackageLocation="$(build.artifactStagingDirectory)\WebApp.zip" /p:DeployIisAppPath="Default Web Site"'
    platform: 'Any CPU'
    configuration: 'Release'

Ketika Anda mereferensikan pool windows-latest di alur YAML Anda, itu masih akan berarti windows-2019 dan bukan windows-2022, sedangkan yang terakhir masih dalam tahap pratinjau.

Gambar alur Windows Server 2022 memiliki alat dan versi alat yang berbeda jika dibandingkan dengan Windows Server 2019. Anda dapat melihat detail dalam isu pengumuman perangkat lunak dan di repositori dokumentasi lingkungan virtual.

Ketersediaan umum macOS 11 pada agen yang dihosting Microsoft

macOS 11 sekarang tersedia secara umum di agen yang dihosting Microsoft. Anda dapat menggunakannya dengan merujuk macos-11 sebagai gambar dalam pipeline Anda.

pool:
  vmImage: macos-11

Penghapusan gambar Ubuntu 16.04 pada agen yang dihosting Microsoft

Seperti yang diumumkan sebelumnya, kami akan menghapus gambar Ubuntu 16.04 dari agen yang dihosting Microsoft pada 20 September 2021. Dukungan tradisional 5 tahun Ubuntu 16.04 oleh Canonical berakhir pada Bulan April 2021. Anda harus memigrasikan alur ubuntu-16.04 ke ubuntu-18.04 atau ubuntu-latest yang akan berjalan pada Ubuntu 20.04 LTS.

Build yang menggunakan Ubuntu-16.04 sudah memiliki peringatan yang dicatat di dalamnya. Untuk memastikan semua orang mengetahui perubahan ini, kami menjadwalkan dua penghentian daya sementara yang singkat. Build Ubuntu 16.04 akan gagal selama periode brownout. Oleh karena itu, disarankan untuk memigrasikan alur kerja Anda sebelum 6 September 2021.

Brownout dijadwalkan untuk tanggal dan waktu berikut (Perhatikan bahwa ini telah diperpanjang satu jam dari waktu yang diumumkan sebelumnya): 6 September 2021 16:00 UTC – 22:00 UTC 14 September 2021 16:00 – 22:00 UTC

Azure Repos

Halaman TFVC baru secara umum tersedia

Kami telah memperbarui berbagai halaman di Azure DevOps untuk menggunakan platform web baru dengan tujuan membuat pengalaman lebih konsisten dan lebih mudah diakses di berbagai layanan. Halaman TFVC telah diperbarui untuk menggunakan platform web baru, dan perubahan tersebut telah dalam pratinjau selama beberapa bulan sekarang. Dengan pembaruan ini, kami membuat halaman TFVC baru tersedia secara umum. Dengan pembaruan ini, Anda tidak akan lagi melihat fitur pratinjau yang disebut "Halaman TFVC Baru" di pengaturan pengguna mereka.

Konfigurasikan agar para pembuat cabang tidak mendapatkan "Kelola izin" pada cabang mereka.

Saat Anda membuat cabang baru, Anda dapat mengelola izin pada cabang tersebut. Izin ini memungkinkan Anda mengubah izin pengguna lain atau mengakui pengguna tambahan untuk berkontribusi ke cabang tersebut. Misalnya, pembuat cabang dapat menggunakan izin ini untuk memungkinkan pengguna eksternal lain membuat perubahan pada kode. Atau, mereka dapat mengizinkan alur (membangun identitas layanan) untuk mengubah kode di cabang tersebut. Di organisasi tertentu dengan persyaratan kepatuhan yang lebih tinggi, pengguna seharusnya tidak dapat membuat perubahan tersebut.

Dengan pembaruan ini, Anda dapat mengonfigurasi setiap dan semua repositori dalam proyek tim Anda dan membatasi pembuat cabang untuk mendapatkan izin "Kelola izin". Untuk melakukan ini, navigasikan ke pengaturan proyek, pilih Repositori, lalu Pengaturan untuk semua repositori atau repositori tertentu.

Semua pengaturan repositori

Pengaturan ini aktif secara default untuk meniru perilaku yang ada. Tapi, Anda dapat menonaktifkannya jika Anda ingin menggunakan fitur keamanan baru ini.

Mencegah pengguna fork untuk memilih pada PR upstream mereka

Dengan Azure Repos, pengguna dengan izin "baca" pada repositori dapat membuat fork repositori dan membuat perubahan di fork mereka. Untuk mengirimkan permintaan pull dengan perubahan mereka ke upstream, pengguna perlu izin "berkontribusi pada permintaan pull" di upstream. Namun, izin ini juga mengatur siapa yang dapat memberikan suara pada pull request di repositori hulu. Akibatnya, Anda dapat berakhir dalam situasi di mana pengguna, yang bukan kontributor ke repositori, dapat mengirimkan permintaan pull dan menyebabkannya digabungkan tergantung pada cara Anda menyiapkan kebijakan cabang.

Dalam organisasi yang mempromosikan model sumber dalam, "fork-and-contribute" adalah pola umum. Untuk mengamankan dan mempromosikan pola ini lebih lanjut, kami mengubah izin untuk memberikan suara pada permintaan pull dari "berkontribusi pada permintaan pull" menjadi "berkontribusi". Namun, perubahan ini tidak dilakukan secara default di semua organisasi. Anda harus ikut serta dan memilih kebijakan baru di repositori Anda, yang disebut "Mode Pemungutan Suara Ketat" untuk mengalihkan izin ini. Kami sarankan Anda melakukannya jika Anda bergantung pada fork di Azure Repos.

Pengaturan repositori

Langkah selanjutnya

Nota

Fitur-fitur ini akan diluncurkan selama dua hingga tiga minggu ke depan.

Buka Azure DevOps dan lihat.

Pergi ke Azure DevOps

Cara memberikan umpan balik

Kami akan senang mendengar apa yang Anda pikirkan tentang fitur-fitur ini. Gunakan menu bantuan untuk melaporkan masalah atau memberikan saran.

Buat saran

Anda juga bisa mendapatkan saran dan pertanyaan yang dijawab oleh komunitas di Stack Overflow.

Terima kasih

Aaron Hallberg

  • Last updated on