Sdílet prostřednictvím

Publikování neutrálního stavu na GitHubu při ověřovacích spuštěních s pravidlem vyloučení cesty

  • Článek

Do této aktualizace jsme zahrnuli několik aktualizací služby Azure Pipelines. U kanálů YAML nastavujeme pro chráněné prostředky jako výchozí odepření přístupu ke všem kanálům. Azure Pipelines navíc publikuje neutrální stav zpět na GitHub, když se rozhodne nespouštět ověřovací sestavení kvůli pravidlu vyloučení cesty.

Podrobnosti najdete v následujících popisech funkcí.

Poznámka

28. září 2021 společnost Axosoft oznámila Azure DevOps na ohrožení zabezpečení v závislosti svého oblíbeného klienta git GUI – GitKraken. Další podrobnosti najdete v blogovém příspěvku .

Azure Pipelines

Azure Pipelines

Post neutral status to GitHub when a build is skipped

Se službou Azure Pipelines můžete vždy ověřit žádost o přijetí změn v GitHubu. Můžete také určit, které cesty ve vašem úložišti GitHubu by měly kanál aktivovat. Například následující kanál se aktivuje, když se do větve nasdílí codemain změna, ale neaktivuje se při odeslání změny do docs složky.

trigger: none

pr:
 branches:
   include:
     - main
 paths:
   include:
     - code
   exclude:
     - docs

pool:
  vmImage: ubuntu-latest

steps:
- script: echo Hello, world!
  displayName: 'Run a one-line script'

Jakmile se kanál dokončí, Azure Pipelines publikuje stav zpět do GitHubu. Pokud pro vaše úložiště GitHub platí zásady ochrany větví, pak stav publikovaný službou Azure Pipelines určil, jestli se žádost o přijetí změn sloučí.

Pokud jste ve výše uvedeném příkladu provedli změnu docs, GitHub aktuálně blokuje žádost o přijetí změn a čeká na vrácení stavu službou Azure Pipelines. Azure Pipelines ale nespustí ověřovací sestavení, protože tato cesta je z triggeru vyloučená, takže není možné dokončit žádost o přijetí změn. Zákazníci, kteří pro jedno úložiště GitHub často nastavují triggery vyloučení cesty nebo více kanálů, často čelili tomuto problému.

V budoucnu neutral azure Pipelines publikuje stav zpět na GitHub, když se rozhodne nespouštět ověřovací sestavení kvůli pravidlu vyloučení cesty. Tím se gitHubu jasně nasměruje, že služba Azure Pipelines dokončila zpracování.

Zobrazení konverzace:

Zobrazení konverzace

Zkontrolujte podrobnosti:

Kontrola podrobností

Přístup ke všem kanálům je ve výchozím nastavení v chráněných prostředcích vypnutý.

Kanál YAML se může spoléhat na jeden nebo více chráněných prostředků. Příkladem chráněných prostředků jsou připojení služeb, fondy agentů, skupiny proměnných, zabezpečené soubory a úložiště, protože správce takového prostředku může řídit, které kanály mají přístup k tomuto prostředku. Správci používají panel nastavení zabezpečení prostředku k povolení nebo zakázání kanálů.

Když vytvoříte některý z těchto prostředků, výchozí prostředí udělí přístup ke všem kanálům, pokud ho explicitně nevypnete. V rámci zlepšení celkového stavu zabezpečení je výchozí nastavení odepření přístupu ke všem kanálům. Pokud chcete udělit přístup ke všem kanálům, jednoduše zapněte přepínač v prostředí pro vytváření nebo po vytvoření prostředku.

Nové připojení služby Azure

Vložení úkolu před nebo za zadané cílové úkoly pomocí dekorátoru

Dekorátory představují způsob, jak automaticky vkládat úkoly do kanálu. Centrální týmy v organizaci je běžně používají k automatickému spouštění požadovaných postupů dodržování předpisů. Dekorátory lze použít s klasickými buildy, klasickými verzemi nebo kanály YAML.

V současné době může být úkol vložen prostřednictvím dekorátoru na začátku každé úlohy, na konci každé úlohy nebo hned po vyřazení úkolu. Chcete-li to řídit, zadáte target v části příspěvku rozšíření dekorátoru, jak je popsáno zde. Seznam cílů teď rozšiřujeme o následující:

ms.azure-pipelines-agent-job.pre-task-tasks
ms.azure-pipelines-agent-job.post-task-tasks
ms.azure-release-pipelines-agent-job.pre-task-tasks
ms.azure-release-pipelines-agent-job.post-task-tasks

Tady je příklad dekorátoru, který vloží úkol před každou instanci PublishPipelineArtifacts úkolu do kanálu.

{
    "manifestVersion": 1,
    "contributions": [
        {
            "id": "my-required-task",
            "type": "ms.azure-pipelines.pipeline-decorator",
            "targets": [
                "ms.azure-pipelines-agent-job.pre-task-tasks"
            ],
            "properties": {
                "template": "my-decorator.yml",
                "targettask": "ECDC45F6-832D-4AD9-B52B-EE49E94659BE"
            }
        }
    ],
    "files": [
        {
            "path": "my-decorator.yml",
            "addressable": true,
            "contentType": "text/plain"
        }
    ]
}

Oznámení plánu vyřazení hostovaných imagí ve Windows 2016

Nedávno jsme systém Windows 2022 zpřístupnili jako hostované image. S blížícím se koncem hlavní fáze technické podpory pro Windows 2016 v lednu 2022 vyřazujeme vs2017-win2016 image od 15. listopadu. Úplné vyřazení této image je naplánováno na březen 2022. Vzhledem k tomu, že se jedná o běžně používanou image, chtěli jsme vám dát dostatek upozornění a času na provedení potřebných změn ve vašich kanálech.

Projděte si náš blogový příspěvek s podrobnými informacemi o tom, jak najít všechny projekty a kanály pomocí image hostované ve Windows 2016, a postup migrace na novější verze.

Oznámení o vyřazení hostovaných imagí macOS 10.14

Nedávno jsme macOS-11 zpřístupnili jako hostované image. V důsledku toho v prosinci 2021 vyřadíme image macOS-10.14. Sestavení, která se spoléhají na tuto image, selžou, jakmile je zastaralá. Další podrobnosti o vyřazení různých obrázků najdete v našem blogovém příspěvku.

Další kroky

Poznámka

Tyto funkce budou zavádět během následujících dvou až tří týdnů.

Přejděte na Azure DevOps a podívejte se.

Přejít na Azure DevOps

Jak poskytnout zpětnou vazbu

Rádi bychom slyšeli, co si o těchto funkcích myslíte. Pomocí nabídky nápovědy můžete nahlásit problém nebo poskytnout návrh.

Vytvoření návrhu

Můžete také získat rady a odpovědi na vaše otázky od komunity na Webu Stack Overflow.

Díky,

Vijay Machiraju