ეს ბრაუზერი აღარ არის მხარდაჭერილი.
გადადით Microsoft Edge-ზე, რათა ისარგებლოთ უახლესი ფუნქციებით, უსაფრთხოების განახლებებითა და ტექნიკური მხარდაჭერით.
In response to your feedback, we have prioritized multiple features that you have requested in the Developer Community. In Pipelines, we added support for string split function in YAML expression. In addition, we are now letting you disable showing the last commit message for a pipeline run. In Delivery Plans, we increased the team limit from 15 to 20.
Check out the release notes for details.
Delivery Plans lets you view multiple backlogs and multiple teams across your organization. Previously, you could view 15 team backlogs, including a mix of backlogs and teams from different projects. In this sprint we increased the maximum limit from 15 to 20.
We fixed a bug in the Reporting Work Item Links Get API to return the correct remoteUrl value for System.LinkTypes.Remote.Related link types. Before this fix, we were returning the wrong organization name and a missing project id.
In this sprint we fixed multiple bugs for New Boards Hub. You can see a list of bug fixes in the New Boards Hub, Sprint 209 update blog post.
Previously, the Pipelines UI used to show the last commit message when displaying a pipeline's run.
This message can be confusing, for example, when your YAML pipeline's code lives in a repository different from the one that holds the code it's building. We heard your feedback from the Developer Community asking us for a way to enable/disable appending the latest commit message to the title of every pipeline run.
With this update, we've added a new YAML property, named appendCommitMessageToRunName, that lets you do exactly that. By default, the property is set to true. When you set it to false, the pipeline run will only display the BuildNumber.
The extended Pipelines Runs REST API now returns more types of artifacts used by a pipeline run and the parameters used to trigger that run. We enhanced the API to return the container and pipeline resources and the template parameters used in a pipeline run. You can now, for example, write compliance checks that evaluate the repositories, containers, and other pipeline runs used by a pipeline.
Here is an example of the new response body.
"resources":
{
"repositories":
{
"self":
{
"repository":
{
"id": "e5c55144-277b-49e3-9905-2dc162e3f663",
"type": "azureReposGit"
},
"refName": "refs/heads/main",
"version": "44153346ecdbbf66c68c20fadf27f53ea1394db7"
},
"MyFirstProject":
{
"repository":
{
"id": "e5c55144-277b-49e3-9905-2dc162e3f663",
"type": "azureReposGit"
},
"refName": "refs/heads/main",
"version": "44153346ecdbbf66c68c20fadf27f53ea1394db7"
}
},
"pipelines":
{
"SourcePipelineResource":
{
"pipeline":
{
"url": "https://dev.azure.com/fabrikam/20317ad0-ae49-4588-ae92-6263028b4d83/_apis/pipelines/51?revision=3",
"id": 51,
"revision": 3,
"name": "SourcePipeline",
"folder": "\\source"
},
"version": "20220801.1"
}
},
"containers":
{
"windowscontainer":
{
"container":
{
"environment":
{
"Test": "test"
},
"mapDockerSocket": false,
"image": "mcr.microsoft.com/windows/servercore:ltsc2019",
"options": "-e 'another_test=tst'",
"volumes":
[
"C:\\Users\\fabrikamuser\\mount-fabrikam:c:\\mount-fabrikam"
],
"ports":
[
"8080:80",
"6379"
]
}
}
}
},
"templateParameters":
{
"includeTemplateSteps": "True"
}
YAML pipelines provide you convenient ways to reduce code duplication, such as looping through each value of a list or property of an object.
Sometimes, the set of items to iterate through is represented as a string. For example, when the list of environments to deploy to is defined by the string integration1, integration2.
As we listened to your feedback from the Developer Community, we heard you wanted a string split function in YAML template expressions.
Now, you can split a string and iterate over each of its substrings.
variables:
environments: integration1, integration2
jobs:
- job: Deploy
steps:
- ${{ each env in split(variables.environments, ', ') }}:
- script: ./deploy.sh -e ${{ env }}
- script: ./runTest.sh -e ${{ env }}
The checkout task uses --tags option in fetching the contents of a Git repository. This causes the server to fetch all tags as well as all objects that are pointed to by those tags. This increases the time to run the task in a pipeline - particularly if you have a large repository with a number of tags. Furthermore, the checkout task syncs tags even when you enable the shallow fetch option, thereby possibly defeating its purpose. To reduce the amount of data fetched or pulled from a Git repository, we have now added a new option to the task to control the behavior of syncing tags. This option is available both in classic and YAML pipelines.
This behavior can either be controlled from the YAML file or from the UI.
To opt-out from syncing the tags through YAML file, add the fetchTags: false to the checkout step. When the fetchTags option is not specified, it's the same as if fetchTags: true is used.
steps:
- checkout: self # self represents the repo where the initial Pipelines YAML file was found
clean: boolean # whether to fetch clean each time
fetchTags: boolean # whether to sync the tags
fetchDepth: number # the depth of commits to ask Git to fetch
lfs: boolean # whether to download Git-LFS files
submodules: boolean | recursive # set to 'true' for a single level of submodules or 'recursive' to get submodules of submodules
path: string # path to check out source code, relative to the agent's build directory (e.g. \_work\1)
persistCredentials: boolean # set to 'true' to leave the OAuth token in the Git config after the initial fetch
If you want to change the behavior of existing YAML pipelines, it may be more convenient to set this option in the UI instead of updating the YAML file. To navigate to the UI, open the YAML editor for the pipeline, select Triggers, then Process, and then the Checkout step.
If you specify this setting both in the YAML file and in the UI, then the value specified in the YAML file takes precedence.
For all new pipelines you create (YAML or Classic), tags are still synced by default. This option does not change the behavior of existing pipelines. Tags will still be synced in those pipelines unless you explicitly change the option as described above.
Azure Pipelines is deprecating the Ubuntu 18.04 image (ubuntu-18.04) on our hosted pools. This image will be retired December 1st. You may start to see longer queue times.
To help you better identify which pipelines are using the ubuntu-18.04 image, we are planning brownouts. Jobs will fail during a brownout period.
Note
These features will roll out over the next two to three weeks.
Head over to Azure DevOps and take a look.
We would love to hear what you think about these features. Use the help menu to report a problem or provide a suggestion.
You can also get advice and your questions answered by the community on Stack Overflow.
Thanks,
Aaron Hallberg
ღონისძიებები
შექმენით AI აპლიკაციები და აგენტები
Mar 17, 9 PM - Mar 21, 10 AM
შემოუერთდით Meetup სერიას, რათა შექმნათ მასშტაბური AI გადაწყვეტილებები რეალურ სამყაროში გამოყენების შემთხვევებზე დაყრდნობით თანამემამულე დეველოპერებთან და ექსპერტებთან.
დარეგისტრირდით ახლავეტრენინგი
სასწავლო გეგმა
Deploy applications with Azure DevOps learning path - Training
Learn how to configure release pipelines that continuously build, test, and deploy your applications.
სერტიფიკაცია
Microsoft Certified: DevOps Engineer Expert - Certifications
This certification measures your ability to accomplish the following technical tasks: Design and implement processes and communications, design and implement a source control strategy, design and implement build and release pipelines, develop a security and compliance plan, and implement an instrumentation strategy.
