What’s new in Azure DevOps Sprint 149?
Sprint 149 has just finished rolling out to all organisations today and you can check out all the cool features in the release notes. Here is just a snapshot of some of the features that you can start using today.
Navigate to Azure Boards work items directly from mentions in any GitHub comment
Want to mention a work item in a GitHub comment? Well, now you can. When you mention a work item within the comment of an issue, pull request, or commit in GitHub using the AB#{work item ID} syntax, those mentions will become hyperlinks that you can click on to navigate directly to the mentioned work item.
This doesn’t create a formal link that clutters up the work item in Azure Boards for every related conversation, but instead gives your team a way to provide a little more information about work items while discussing code or a customer-reported issue. Check out the Azure Boards GitHub integration documentation for more information.
Azure Boards GitHub Enterprise support
Teams can now connect Azure Boards projects to repositories hosted in GitHub Enterprise Server instances. By connecting your Azure DevOps Server project with your GitHub Enterprise Server repositories, you support linking between GitHub commits and pull requests to work items. You can use GitHub Enterprise for software development while using Azure Boards to plan and track your work. Follow the steps in the documentation to get started.
Private projects now get 60 minutes of run time per pipeline job
In this sprint, a free account (that is, one which had not purchased parallel jobs) can now run a job for up to 60 minutes at a time (instead of the 30 mins), with up to 1,800 minutes per month. If you need to run your pipeline for more than 60 minutes, you can pay for additional capacity per parallel job or run in a self-hosted agent. Self-hosted agents don’t have a job length restrictions. Learn more about pricing here.
GitHub comments trigger optimizations
We improved the experience for teams who use GitHub pull request comments to trigger builds. Usually for security, these teams don’t want to automatically build pull requests. Instead, they want a team member to review the pull request and once it’s deemed safe, trigger the build with a pull request comment. Adding this new setting, helps with this, whilst still allowing automatic pull request builds only for team members.
These are just the tip of the iceberg, and there is plenty more that we’ve released in Sprint 149. Check out the full list of features for this sprint in the release notes.
Light
Dark
0 comments