Supporto per le espressioni modello nelle definizioni di risorse del repository e del contenitore
Con questo aggiornamento è stato incluso il supporto per le espressioni modello nelle definizioni di repository e risorse del contenitore. È ora possibile usare espressioni modello quando si definisce la ref proprietà di una repository risorsa in una pipeline YAML per scegliere il ramo di una risorsa del repository. È stato inoltre aggiunto il supporto per le espressioni modello quando si definiscono le endpointproprietà , volumes, portse options di una container risorsa in una pipeline YAML.
Per informazioni dettagliate, vedere le note sulla versione.
Azure Boards
- Modificare i tipi di collegamento degli elementi di lavoro
- Creare un endpoint REST di query temporaneo
- API di eliminazione batch (anteprima privata)
- macro @CurrentIteration nei piani di recapito
Azure Pipelines
- Espressioni modello nella definizione della risorsa del repository
- Espressioni modello nella definizione di risorsa contenitore
- Eventi di controllo per le modifiche alle approvazioni
- La libreria di attività espone il modello di hosting di Agent
Azure Boards
Modificare i tipi di collegamento degli elementi di lavoro
In precedenza, la modifica di un collegamento a un elemento di lavoro richiede almeno tre passaggi da completare. Ad esempio, per modificare un collegamento padre a un collegamento correlato, è necessario copiare l'ID elemento di lavoro, rimuovere il collegamento padre, aggiungere un nuovo collegamento esistente di tipo correlato e infine incollare l'ID copiato e salvare. È un processo complesso.
Il problema è stato risolto consentendo di modificare e modificare direttamente il tipo di collegamento. È possibile modificare rapidamente il tipo di collegamento in un solo passaggio.
Creare un endpoint REST di query temporaneo
Sono state viste diverse istanze degli autori di estensioni che tentano di eseguire query non salvate passando l'istruzione WIQL (Work Item Query Language) tramite la querystring. Questa operazione funziona correttamente, a meno che non si disponga di un'istruzione WIQL di grandi dimensioni che raggiunge i limiti del browser sulla lunghezza della stringa di query. Per risolvere questo problema, è stato creato un nuovo endpoint REST per consentire agli autori di strumenti di generare una query temporanea. L'uso dell'ID dalla risposta per passare tramite querystring elimina questo problema.
Per altre informazioni, vedere la pagina della documentazione dell'API REST query temporanee.
API di eliminazione batch (anteprima privata)
Attualmente, l'unico modo per rimuovere elementi di lavoro dal Cestino consiste nell'usare questa API REST per eliminarli uno alla volta. Questo può essere un processo lento ed è soggetto a limitazione della frequenza quando si tenta di eseguire qualsiasi tipo di pulizia di massa. In risposta, è stato aggiunto un nuovo endpoint DELL'API REST per eliminare e/o eliminare definitivamente gli elementi di lavoro in batch.
Se si è interessati a partecipare a un'anteprima privata di questo nuovo endpoint, inviare direttamente un messaggio di posta elettronica.
@CurrentIteration macro nei piani di recapito
Con questo aggiornamento è stato aggiunto il supporto per la macro per gli @CurrentIteration stili nei piani di recapito. Questa macro consentirà di ottenere l'iterazione corrente dal contesto del team di ogni riga del piano.
Azure Pipelines
Espressioni modello nella definizione della risorsa del repository
È stato aggiunto il supporto per le espressioni modello quando si definisce la ref proprietà di una repository risorsa in una pipeline YAML. Questa è stata una funzionalità molto richiesta dalla community degli sviluppatori.
Esistono casi d'uso quando si vuole che la pipeline esestraa rami diversi della stessa risorsa del repository.
Si supponga, ad esempio, di avere una pipeline che compila il proprio repository e, per questo, deve controllare una libreria da un repository di risorse. Si supponga inoltre di voler controllare lo stesso ramo di libreria usato dalla pipeline stessa. Ad esempio, se la pipeline viene eseguita nel main ramo, deve controllare il main ramo del repository di libreria. Se le pipeline vengono eseguite nel dev ramo, è necessario controllare il ramo della dev libreria.
Fino ad oggi, è necessario specificare in modo esplicito il ramo da archiviare e modificare il codice della pipeline ogni volta che il ramo cambia.
A questo punto, è possibile usare espressioni modello per scegliere il ramo di una risorsa del repository. Vedere l'esempio seguente di codice YAML da usare per i rami non principali della pipeline:
resources:
repositories:
- repository: library
type: git
name: FabrikamLibrary
ref: ${{ variables['Build.SourceBranch'] }}
steps:
- checkout: library
- script: echo ./build.sh
- script: echo ./test.sh
Quando si esegue la pipeline, è possibile specificare il ramo da controllare per il library repository.
Specificare la versione di un modello da estendere in fase di coda di compilazione
I modelli rappresentano un ottimo modo per ridurre la duplicazione del codice e migliorare la sicurezza delle pipeline.
Un caso d'uso comune consiste nel ospitare i modelli nel proprio repository. In questo modo si riduce l'accoppiamento tra un modello e le pipeline che lo estendono e semplifica l'evoluzione del modello e delle pipeline in modo indipendente.
Si consideri l'esempio seguente, in cui viene usato un modello per monitorare l'esecuzione di un elenco di passaggi. Il codice del modello si trova nel Templates repository.
# template.yml in repository Templates
parameters:
- name: steps
type: stepList
default: []
jobs:
- job:
steps:
- script: ./startMonitoring.sh
- ${{ parameters.steps }}
- script: ./stopMonitoring.sh
Si supponga di avere una pipeline YAML che estende questo modello, che si trova nel repository FabrikamFiber. Fino ad oggi, non era possibile specificare dinamicamente la ref proprietà della templates risorsa del repository quando si usa il repository come origine modello. Ciò significa che è stato necessario modificare il codice della pipeline se si vuole che la pipeline: estendere un modello da un ramo diverso estende un modello dallo stesso nome di ramo della pipeline, indipendentemente dal ramo in cui è stata eseguita la pipeline
Con l'introduzione delle espressioni modello nella definizione della risorsa del repository, è possibile scrivere la pipeline come segue:
resources:
repositories:
- repository: templates
type: git
name: Templates
ref: ${{ variables['Build.SourceBranch'] }}
extends:
template: template.yml@templates
parameters:
steps:
- script: echo ./build.sh
- script: echo ./test.sh
In questo modo, la pipeline estenderà il modello nello stesso ramo del ramo in cui viene eseguita la pipeline, in modo da assicurarsi che i rami della pipeline e del modello corrispondano sempre. Ovvero, se si esegue la pipeline in un ramo dev, il modello specificato dal template.yml file nel dev ramo del templates repository verrà esteso.
In alternativa, è possibile scegliere, in fase di compilazione, quale ramo del repository di modelli usare, scrivendo il codice YAML seguente.
parameters:
- name: branch
default: main
resources:
repositories:
- repository: templates
type: git
name: Templates
ref: ${{ parameters.branch }}
extends:
template: template.yml@templates
parameters:
steps:
- script: echo ./build.sh
- script: echo ./test.sh
A questo punto, è possibile avere la pipeline nel ramo main estendere un modello da un ramo dev in un'unica esecuzione ed estendere un modello da un ramo main in un'altra esecuzione, senza modificare il codice della pipeline.
Quando si specifica un'espressione modello per la ref proprietà di una risorsa del repository, è possibile usare parameters le variabili predefinite di sistema e di sistema, ma non è possibile usare variabili definite dall'interfaccia utente YAML o Pipelines.
Espressioni modello nella definizione di risorsa contenitore
È stato aggiunto il supporto per le espressioni modello quando si definiscono le endpointproprietà , volumesports, e options di una container risorsa in una pipeline YAML. Questa è stata una funzionalità molto richiesta dalla community degli sviluppatori.
È ora possibile scrivere pipeline YAML come le seguenti.
parameters:
- name: endpointName
default: AzDOACR
type: string
resources:
containers:
- container: linux
endpoint: ${{ parameters.endpointName }}
image: fabrikamfiber.azurecr.io/ubuntu:latest
jobs:
- job:
container: linux
steps:
- task: CmdLine@2
inputs:
script: 'echo Hello world'
È possibile usare parameters. e variables. nelle espressioni del modello. Per le variabili, è possibile usare solo quelli definiti nel file YAML, ma non quelli definiti nell'interfaccia utente di Pipelines. Se si ridefinisce la variabile, ad esempio usando i comandi di log dell'agente, non avrà alcun effetto.
Eventi di controllo per le modifiche alle approvazioni
Le approvazioni consentono di controllare quando deve essere eseguita una fase. Viene comunemente usato per controllare le distribuzioni in ambienti di produzione. Il controllo consente di soddisfare i requisiti di conformità e monitorare la sicurezza dell'organizzazione Azure DevOps.
Quando viene chiesto a un utente di approvare una pipeline da distribuire in una fase specifica, tale utente può scegliere di riassegnare l'approvazione a un altro utente.
Fino ad ora, tali azioni non sono state registrate nei log di controllo. Questo problema è stato risolto.
I log di controllo conterranno una voce simile alla seguente.
[
{
"Id": "2517368925862632546;00000264-0000-8888-8000-000000000000;839ad1ba-f72b-4258-bc3f-88be7a4553b5",
"CorrelationId": "aaaa0000-bb11-2222-33cc-444444dddddd",
"ActivityId": "a298a06c-965f-4e60-9643-2593f2066e37",
"ActorCUID": "fe950802-bf07-755b-826d-e8dcc066252c",
"ActorUserId": "fe950802-bf07-755b-826d-e8dcc066252c",
"ActorUPN": "silviu@fabrikam.app",
"AuthenticationMechanism": "AAD_Cookie",
"Timestamp": "2022-10-10T11:26:53.7367453Z",
"ScopeType": "Organization",
"ScopeDisplayName": "Fabrikam (Organization)",
"ScopeId": "547a7316-cdf4-40d2-af16-3215f97d053e",
"ProjectId": "4bf16944-3595-421f-9947-79d9eb190284",
"ProjectName": "FabrikamFiber",
"IpAddress": "127.0.0.1",
"UserAgent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/106.0.0.0 Safari/537.36 Edg/106.0.1370.37",
"ActionId": "ApproverReassigned",
"Data": {
"ApprovalId": "dae6e7c9-2a10-4cd8-b63a-579a6e7ba78d",
"OldApproverUserId": "692b6e2a-dd61-4872-866a-85498da390fc",
"OldApproverDisplayName": "[FabrikamFiber]\\Build Administrators",
"NewApproverUserId": "fe95080b-bf07-655b-226d-e8dcc066252c",
"NewApproverDisplayName": "Jack Fabrikam",
"Comment": "All admins are OOO"
},
"Details": "Reassigned approver of Approval dae6e7c9-9a10-4cd8-b63a-579a6e7ba78d in Project \"FabrikamFiber\" from \"[FabrikamFiber]\\Build Administrators\" to \"Jack Fabrikam\" with comment \"All admins are OOO\".",
"Area": "Checks",
"Category": "Modify",
"CategoryDisplayName": "Modify",
"ActorDisplayName": "Silviu"
}
]
Inoltre, verrà visualizzato nell'interfaccia utente di controllo.
La libreria di attività espone il modello di hosting di Agent
Autori di attività che vogliono determinare se un agente è in esecuzione in pool ospitati da Microsoft o non può ora usare la funzione getAgentMode() Libreria attività per determinare il modello di hosting. Ciò è utile negli scenari in cui un'attività vuole influenzare il comportamento in base alla presenza o meno dell'accesso alla rete di un cliente. Un'attività può provare a raggiungere un servizio di Azure tramite un endpoint privato se viene eseguita da un agente self-hosted o da agenti del set di scalabilità che risiedono nella rete di un cliente.
Vedere le informazioni di riferimento sulle attività.
Passaggi successivi
Nota
Queste funzionalità verranno implementate nelle prossime due o tre settimane.
Passare ad Azure DevOps e dare un'occhiata.
Come fornire commenti e suggerimenti
Ci piacerebbe sentire ciò che pensi a queste funzionalità. Usare il menu ? per segnalare un problema o fornire un suggerimento.
È anche possibile ottenere consigli e risposte alle domande della community su Stack Overflow.
Grazie,
Vijay Machiraju