A Small Request Re: Version Numbers
Usb to serial adapter driver windows 10. Note If you are accessing this page from a non-English language version, and want to see the most up-to-date content, please visit this Release Notes page in. You can change the language of this page by clicking the globe icon in the and selecting your desired language. In this article, you will find information regarding the newest release for Team Foundation Server 2018. Click the button to download.
To learn more about Team Foundation Server 2018, see the page. Visit the page to download other TFS 2018 products. Direct upgrade to Team Foundation Server 2018 Update 2 is supported from TFS 2012 and newer. If your TFS deployment is on TFS 2010 or earlier, you need to perform some interim steps before upgrading to TFS 2018 Update 2.
Please see the chart below and the for more information. TFS Upgrade Matrix. Important You do not need to upgrade to TFS 2018 RTM before upgrading to TFS 2018 Update 2. Release Date: May 7, 2018 You can now upgrade to TFS 2018 Update 2 and continue to. When we removed support for XAML build in TFS 2018 RTW and Update 1, some of you could not upgrade due to having legacy XAML builds, and we want to unblock you. Although TFS 2018 Update 2 supports XAML builds for your legacy builds, XAML build is deprecated and there will be no further investment, so we highly recommend converting to a newer build definition format.
Summary of What's New in TFS 2018 Update 2 We have added a lot of new value to Team Foundation Server 2018 Update 2. Some of the highlights include:. Details of What's New in TFS 2018 Update 2 You can find details about features in each area:. Code Get a permanent link to code When viewing a file, you usually see the version at the tip of the selected branch. The version of a file at the tip may change with new commits. If you copy a link from this view, your links can become stale because the URL only includes the branch name, not the commit SHA.
You can now easily switch the Files view to update the URL to refer to the commit rather than the branch. If you press the 'y' key, your view switches to the tip commit of the current branch. You can then copy permanent links. Recover a recently-deleted repository through API Sometimes mistakes can be made when cleaning up old repositories in source control. If a Git repository is deleted within the last 30 days, it can be recovered through the REST API.
See the documentation for the and operations for more information. SSH: Support additional ciphers/keys and deprecate outdated ciphers To improve security and compatibility, we have updated the list of ciphers supported for SSH. We have added two new ciphers and deprecated three, matching OpenSSH's direction. The deprecated ciphers continue to work in this release. They will be removed in the future as usage falls off.
Added:. AES128 CTR.
AES256 CTR Deprecated:. AES128. AES192. AES256 Avoid overwrites and protect performance using repository settings In this Update, you will find two new to help keep Git running smoothly. Case enforcement switches the server from its default case-sensitive mode, where 'File.txt' and 'file.txt' refer to the same file, to a Windows and macOS-friendly mode where 'File.txt' and 'file.txt' are the same file. This setting affects files, folders, branches, and tags.
It also prevents contributors from accidentally introducing. Enabling case enforcement is recommended when most of your contributors are running Windows or macOS.
Limit file sizes allows you to prevent new or updated files from exceeding a size limit you set. The greater number of large files that exist in a Git repository's history, the worse clone and fetch operation performance becomes. This setting prevents accidental introduction of these files. Enhanced filter capability for commits with more than 1000 files changed Searching for a file in commits or pull requests that have modified more than 1000 files was inefficient; you would need to click on Load more link several times to find the file that you were interested in. Now, when you filter content in the tree view, the search for that file is done across all files in the commit instead of just looking at the top 1000 files loaded. The performance of the commit details page is also improved when there are more than 1000 files modified.
Find lost commits due to a Force Push You can perform a Git force push and update a remote ref even if it is not an ancestor of the local ref. This may cause others to lose commits and it can be very hard to identify the root cause. In the new pushes view, we have made force pushes noticeable in order to help troubleshoot issues related to missing commits.
Blame now has history The Blame view is great for identifying the last person to change a line of code. However, sometimes you need to know who made the previous change to a line of code. The newest improvement in blame can help - View blame prior to this commit. As the name suggests, this feature allows you to jump back in time to the version of the file prior to the version that changed a particular line, and view the blame info for that version.
You can continue to drill back in time looking at each version of the file that changed the selected line of code. Toggle word wrap and white space in diff views Two new features are available in the file diff viewer: Toggle Word Wrap and Toggle White Space. The first allows the word wrap setting to be applied while in a diff view. This is particularly useful for reviewing PRs that contain files without frequent line breaks - markdown files are a good example. The option to toggle white space is helpful when only whitespace has changed in a line or file. Toggling this setting displays and highlights the whitespace characters (dots for spaces, arrows for tabs, etc.) in the diff. To manage these settings, click on the editor preferences gear in the pull request editor or diff view.
In the Files view, select the User Preferences option on the right-click menu. Control who can contribute to pull requests Previously, anyone who could view a Git repository could work with its pull requests. We have added a new permission called Contribute to pull requests that controls access to creating and commenting on pull requests. All users and groups that previously held the Read permission are also granted this new permission by default. The introduction of this new permission gives administrators additional flexibility and control. If you require your Readers group to be truly read-only, you can deny the Contribute to pull requests permission.
See the for more information. Pull request comment notifications include the thread context Many times, replies to pull request (PR) comments are pretty brief, acknowledging that a change will be or has been made. This is not a problem when viewing these comments in the web view, but if you are reading a comment in an email notification, the context of the original comment is lost. A simple 'I'll fix it' has no meaning. Now, whenever a reply is made to a PR comment, the comment emails include the prior replies in the body of the email message. This allows the thread participants to see the full context of the comment right from their inbox - no need to open the web view. Complete work items settings The feature to complete work items when completing pull requests now has a new repository setting to control the default behavior.
The new setting to Remember user preferences for completing work items with pull requests is enabled by default, and honors the user's last state when completing future pull requests in the repo. If the new setting is disabled, then the Complete linked work items after merging option defaults to disabled for all pull requests in the repository. Users can still choose to transition linked work items when completing PRs, but they will need to opt-in each time. Pull request status extensibility Using branch policies can be a great way to increase the quality of your code. However, those policies have been limited to only the integrations provided natively by TFS. Using the new pull request Status API and the corresponding branch policy, third party services can participate in the pull request workflow just like native TFS features. When a service posts to the Status API for a pull request, it immediately appears in the PR details view in a new Status section.
The status section shows the description and creates a link to the URL provided by the service. Status entries also support an action menu (.) that is extensible for new actions added by web extensions. Once the policy is active, the status is shown in the Policies section, under Required or Optional as appropriate, and the PR completion is enforced as appropriate. To learn more about the status API, and to try it out for yourself, check out the. Pull request service hooks merge events Extensions using pull request service hooks now have more details and filtering options for merge events. Any time a merge is attempted, the event is fired regardless of the success or failure of the merge. When a merge attempt results in a failure, details about the reason for the failure is included. Mention a pull request You can now mention pull requests in PR comments and work item discussions.
The experience for mentioning a PR is similar to that of a work item, but uses an exclamation point! Instead of a hash mark #. Whenever you want to mention a PR, enter a!, and you will see an interactive experience for picking a PR from your list of recent PRs. Enter keywords to filter the list of suggestions, or enter the ID of the PR you want to mention. Once a PR is mentioned, it is rendered inline with the ID and the full title, and it will link to the PR details page. Pull request comments follow renamed files Sometimes files are renamed or moved while a pull request is active. Previously, if there were comments on those renamed files, the latest view of the code would not display the comments. We have now improved comment tracking to follow the renames, displaying comments on the latest version of renamed or moved files.
View pull request merge commit Pull request diff views are great at highlighting the changes introduced in the source branch. However, changes to the target branch may cause the diff view to look different than expected.
A new command is now available to view the diff of the 'preview' merge commit for the pull request - View merge commit. This merge commit is created to check for merge conflicts and to use with a pull request build, and it reflects what the merge commit will look like when the pull request is eventually completed. When the target branch has changes not reflected in the diff, the merge commit diff can be useful for seeing the latest changes in both the source and target branches. Another command that is useful in conjunction with the View merge commit command is Restart merge (available on the same command menu).
If the target branch has changed since the pull request was initially created, running this command creates a new preview merge commit, updating the merge commit diff view. Recently used reviewers If you frequently have your code reviewed by the same individuals, you will find it easier than ever to add reviewers. When adding reviewers to your pull requests, a list of your recently added reviewers is automatically displayed when you put focus into the reviewers input box - no need to search by name.
Select them as you would any reviewer. View remaining policy criteria for pull request auto-complete Auto-complete is a useful feature for teams using branch policies, but when using optional policies, it can be unclear exactly what is blocking a pull request from being completed. Now, when setting auto-complete for a pull request, the exact list of policy criteria that are holding up completion are clearly listed in the callout box.
As each requirement is met, items are removed from the list until there are no remaining requirements and the pull request is merged. Pull request suggestions for forks Whenever a topic branch is updated in a repository, a 'suggestion' to create a new pull request (PR) for the topic branch is shown. This is very useful for creating new PRs, and we have enabled it for those working in a forked repo, too.
If you update a branch in a fork, the next time you visit the Code hub for either the fork or the upstream repo, you will see the suggestion to create a pull request. If you select the 'Create a pull request' link, you will be directed to the create PR experience, with the source and target branches and repos pre-selected. In addition to build, status policies also have the path filtering option available. This allows any custom or third party policies to configure policy enforcement for specific paths. This feature was prioritized based on a. Work Keyboard shortcuts in the work item form Assign a work item to yourself (Alt + i), jump to discussion (Ctrl + Alt + d), and copy a quick link to the work item (Shift + Alt + c) using keyboard shortcuts.
For the full list of new shortcuts, type '?' With a work item form open or see the table below. Query last run by information As your project's Shared Queries tree grows, it can be difficult to determine if a query is no longer used and can be deleted. To help you manage your Shared Queries, we have added two new pieces of metadata to our, last executed by and last executed date, so that you can write clean-up scripts to delete stale queries.
HTML tags stripped in work item grids Based on customer feedback, we have updated the behavior of multi-line text fields in work item query results views in the web, Excel, and Visual Studio IDE to remove HTML formatting. When added as a column to the query, multi-line text fields now display as plain text.
Here is an example of a feature with HTML in the description. Query for @MyRecentActivity and @RecentMentions We have introduced two new query macros for the ID field to help you find work items that may be important to you.
See what items you were mentioned in over the last 30 days using @RecentMentions or take a look at work items you have recently viewed or edited using @MyRecentActivity. Custom fields and tags filter in work item tracking notifications Notifications can now be defined using conditions on custom fields and tags; not only when they change but when certain values are met. This has been a top customer suggestion in UserVoice (see and ), and allows for a more robust set of notifications that can be set for work items. Grant the bypassrule permission to specific users Often, when migrating work items from another source, organizations want to retain all the original properties of the work item.
For example, you may want to create a bug that retains the original created date and created by values from the system where it originated. The API to has a bypassrule flag to enable that scenario.
Previously, the identity who made that API request had to be a member of the Project Collection Administrators group. We have added a permission at the project level to execute the API with the bypassrule flag.
Build and Release XAML builds In TFS 2015, we introduced a web-based, cross-platform build system. XAML builds are not supported in TFS 2018 RTW or Update 1, but we have re-enabled XAML builds in TFS 2018 Update 2. We encourage you to.
When you upgrade to TFS 2018 Update 2:. If you have any XAML build data in your team project collection, you will get a warning about the deprecation of XAML build features. You will need to use VS or Team Explorer 2017 to edit XAML build definitions or to queue new XAML builds. If you need to create new XAML build agents, you will need to install them using the TFS 2015 build agent installer. For an explanation of our XAML build deprecation plan, see the. Enhancements to multi-phase builds You have been able to use phases to organize your build steps and to target different agents using different demands for each phase.
We have added several capabilities to build phases so that you can now:. Specify a different agent queue for each phase. This means you can, for example:. Run one phase of a build on a macOS agent and another phase on a Windows agent. To see a cool example of how useful this can be, see this Connect; 2017 video:.
Run build steps on a build agent pool and test steps on a test agent pool. Run tests faster by running them in parallel.
Any phase that has parallelism configured as 'Multi-agent' and contains a 'VSTest' task now automatically parallelize test execution across the configured agent count. Permit or deny scripts to access the OAuth token each phase. This means, for example, you can now allow scripts running in your build phase to communicate with VSTS over REST APIs, and in the same build definition block the scripts running in your test phase. Run a phase only under specific conditions. For example, you can configure a phase to run only when previous phases succeed, or only when you are building code in the master branch. To learn more, see. Skip scheduled builds if nothing has changed in the repo By, you can now specify that a scheduled build not run when nothing has changed in your code.
You can control this behavior using an option on the schedule. By default, we will not schedule a new build if your last scheduled build (from the same schedule) has passed and no further changes have been checked in to your repo.
Build with continuous integration from GitHub Enterprise You now have better integration for performing continuous integration (CI) builds if you use GitHub Enterprise for version control. Previously, you were limited to polling for code changes using the External Git connector, which may have increased the load on your servers and caused delays before builds were triggered. Now, with official GitHub Enterprise support, team CI builds are immediately triggered. In addition, the connection can be configured using various authentication methods, such as LDAP or built-in accounts. Secure files can be downloaded to agents during build or release The new Download Secure File task supports downloading (to agent machines) encrypted files from the VSTS Secure Files library. As the file is downloaded, it is decrypted and stored on the agent's disk.
When the build or release completes, the file is deleted from the agent. This allows your build or release to use sensitive files, such as certificates or private keys that are otherwise securely encrypted and stored in VSTS. For more information, see. Apple provisioning profiles can be installed from source repositories The Install Apple Provisioning Profile task already supports installing (on agent machines) provisioning profiles that are stored in the VSTS Secure Files library.
Provisioning profiles are used by Xcode to sign and package Apple apps, such as for iOS, macOS, tvOS, and watchOS. Now, provisioning profiles can be installed from source code repositories. Though use of the Secure Files library is recommended for greater security of these files, this improvement addresses provisioning profiles already stored in source control. Specific Java Development Kits (JDKs) can be installed during builds and releases For building certain Java projects, specific JDKs may be required but unavailable on agent machines. For example, projects may require older or different versions of IBM, Oracle, or open-source JDKs. The Java Tool Installer task downloads and installs the JDK needed by your project during a build or release. The JAVAHOME environment variable is set accordingly for the duration of the build or release.
Specific JDKs are available to the Java Tool Installer using a file share, a source code repository, or Azure Blob Storage. Improved Xcode build configuration The Xcode task has been updated with a new major version (4.) that improves configuration of Xcode building, testing, and packaging.
If your Xcode project has a single, shared scheme, it is automatically used. Additional inline help was added.
Deprecated features, such as xcrun packaging, were removed from the Xcode task's properties. Existing build and release definitions must be modified to use this latest 4. version of the Xcode task. For new definitions, if you need a previous Xcode task version's deprecated capabilities, you can select that version in your definition. Release gates Continuous monitoring is an integral part of DevOps pipelines.
Ensuring the app in a release is healthy after deployment is as critical as the success of the deployment process. Enterprises have adopted various tools for automatic detection of app health in production and for keeping track of customer reported incidents. Until now, approvers had to manually monitor the health of the apps from all the systems before promoting the release. However, Release Management now supports integrating continuous monitoring into release pipelines. Use this to ensure the system repeatedly queries all the health signals for the app until all of them are successful at the same time, before continuing the release. You start by defining pre-deployment or post-deployment gates in the release definition.
Each gate can monitor one or more health signals corresponding to a monitoring system of the app. Built-in gates are available for 'Azure monitor (application insight) alerts' and 'Work items'.
You can integrate with other systems using the flexibility offered through Azure functions. Initial samples from the monitoring systems may not be accurate, as not enough information may be available for the new deployment.
The 'Delay before evaluation' option ensures the Release does not progress during this period, even if all samples are successful. No agents or pipelines are consumed during sampling of gates. See the for more information. Deploy selectively based on the artifact triggering a release Multiple artifact sources can be added to a release definition and configured to trigger a release.
A new release is created when a new build is available for either of the sources. The same deployment process is executed regardless of what source triggered the release.
You can now customize the deployment process based on the triggering source. For auto-triggered releases, the release variable Release.TriggeringArtifact.Alias is now populated to identify the artifact source that triggered the release.
This can be used in task conditions, phase conditions, and task parameters to dynamically adjust the process. For example, if you only need to deploy the artifacts that changed through environments. Manage entity-specific security Previously in role based security, when the security access roles were set, they were set for a user or group at hub level for Deployment groups, Variable groups, Agent queues, and Service endpoints. Now you can turn on and off inheritance for a particular entity so you can configure security just the way you want to. Release template extensibility Release templates let you create a baseline for you to get started when defining a release process. Previously, you could upload new ones to your account, but now authors can include release templates in their extensions.
You can find an. Conditional release tasks and phases Similar to, you can now run a task or phase only if specific conditions are met. This will help you in modeling rollback scenarios. If the built-in conditions do not meet your needs, or if you need more fine-grained control over when the task or phase runs, you can specify custom conditions.
Express the condition as a nested set of functions. The agent evaluates the innermost function and works its way outward. The final result is a Boolean value that determines if the task is to be run. Jenkins multi-branch pipeline support and link jobs organized in folders Consuming projects from Jenkins just got even better. First, you can now consume Jenkins multi-branch pipeline projects as artifact sources in a release definition.
Second, while previously you could link Jenkins projects as artifacts only from the root folder of a Jenkins server, now Jenkins projects can be consumed when organized at folder level. You see the list of Jenkins projects, along with folder paths, in the list of sources from which you select the project to be consumed as artifact source.
Docker Hub or Azure Container Registry as an artifact source This feature enables releases to use images stored in a Docker Hub registry or an Azure Container Registry (ACR). This is a first step towards supporting scenarios such as rolling out new changes region-by-region by using the geo-replication feature of ACR or deploying to an environment (such as production) from a container registry that has images for only the production environment.
You can now configure Docker Hub or ACR as a first-class artifact in the + Add artifact experience of a release definition. For now the release has to be triggered manually or by another artifact but we look forward to adding a trigger based on the push of a new image to the registry soon.
Release triggers branch enhancements You can now configure a release trigger filter based on the default branch specified in the build definition. This is particularly helpful if your default build branch changes every sprint and the release trigger filters needs to be updated across all the release definitions. Now you just need to change the default branch in the build definition and all the release definitions automatically use this branch. For example, if your team is creating release branches for each sprint release payload, you update it in the build definition to point to a new sprint release branch and the release picks this up automatically. Release trigger for a package management artifact Now you can set a trigger on a Package Management artifact in a Release definition so that a new release is automatically created when a new version of the package has been published. See the for more information.
Scope a variable group to specific environments Previously, when a variable group was added to a release definition, the variables it contained were available to all the environments in the release. Now, you have the flexibility to scope the variable groups to specific environment(s) instead.
This makes them available to one environment but not other environments of the same release. This is great when you have an external service, such as an SMTP email service, which is different between environments. Specify a default version for Jenkins artifacts When a release with multiple artifacts is auto-triggered, default versions saved in the release definition are picked up for all artifacts.
Previously, Jenkins artifacts did not have a default version setting, and so you couldn't set a continuous deployment trigger on a release using Jenkins as the secondary artifact. Now, you can specify a default version for Jenkins artifacts, with the options you are familiar with:. Latest. Specify at the time of release creation. Specific version. Contribute release gates from extensions Release gates enable addition of information driven approvals to the release pipelines. A set of health signals are collected repeatedly prior to or post deployment, to determine whether the release should be promoted to the next stage or not.
A set of built-in gates are provided, and 'Invoke Azure function' has so far been recommended as a means to integrate with other services. We now simplify the route to integrate with other services and add gates through marketplace extensions. You can now contribute custom gate tasks and provide release definition authors an enhanced experience to configure the gate.
Learn more about. Scale deployments to Virtual Machines using Deployment Groups Deployment Groups, that gives robust, out-of-the-box multi-machine deployment, is now generally available. With Deployment Groups, you can orchestrate deployments across multiple servers and perform rolling updates, while ensuring high availability of your application throughout. You can also deploy to servers on-premises or virtual machines on Azure or any cloud and have end-to-end traceability of deployed artifact versions down to the server level. The agent-based deployment capability relies on the same build and deployment agents that are already available.
You can use the full task catalog on your target machines in the Deployment Group phase. From an extensibility perspective, you can also use the REST APIs for and for programmatic access. Package Seamlessly use public packages using upstream sources Upstream sources for and are now available. Benefits include the ability to manage (unlist, deprecate, unpublish, delete, etc.) packages saved from upstream sources as well as guaranteed saving of every upstream package you use.
Retention policies in TFS feeds Until now, TFS package feeds have not provided any way to automatically clean up older, unused package versions. For frequent package publishers, this could result in slower feed queries in the NuGet Package Manager and other clients until some versions were manually deleted. We have now enabled retention policies on TFS feeds. Retention policies automatically delete the oldest version of a package once the retention threshold is met. Packages promoted to views are retained indefinitely, giving you the ability to protect versions that are used in production or used widely across your organization.
To enable retention policies, edit your feed and enter a value in the Maximum number of versions per package in the Retention policies section. Gulp, Yarn, and more authenticated feed support The npm task today works seamlessly with authenticated npm feeds (in Package Management or external registries like npm Enterprise and Artifactory), but until now it has been challenging to use a task runner like Gulp or an alternate npm client like Yarn unless that task also supported authenticated feeds. We have added a new npm Authenticate build task that adds credentials to your.npmrc so that subsequent tasks can use authenticated feeds successfully. Package feed default permissions now include Project Administrators In the past, creating a feed sets the creating user as the only feed owner, which can cause administration challenges in large organizations if that user switches teams or leaves the organization. To remove this single point of failure, creating a feed now uses the user's current project context to get the Project Administrators group and make it an owner of the feed as well. As with any permission, you can remove this group and further customize feed permissions using the feed settings dialog.
Recycle and restore packages Deleting unused packages can help keep the package list clean but sometimes it can be done by mistake. Now you can restore deleted packages from the Recycle Bin.
Deleted packages are retained in the Recycle Bin for 30 days, giving you ample time to restore if you need to. Link to packages from anywhere Although you could share the URL to a package found in the Packages hub in the past, it was often difficult to use because you needed to include a project in the URL, that may or may not apply to those using the link. With this Update, you can now share packages using a URL that automatically select a project the recipient has access to. The URL format is: `All parameters except `` are optional, but if you provide a package, you must provide the protocol type.
Test Visual Studio Test task does not need full Visual Studio The Visual Studio Test task in build/release requires Visual Studio on the agent to run tests. Rather than installing Visual Studio to run tests in production environments or for merely distributing tests over multiple agents, use the new Visual Studio Test Platform Installer task. This task acquires the and adds it to the tools cache. The installer task satisfies the vstest demand and a subsequent Visual Studio Test task in the definition can run without needing a full Visual Studio install on the agent. From the task catalog, add the installer task in your definition.
Note Limitations: The Test Platform package on NuGet currently does not support running Coded UI test. Enabling support for Coded UI test is on the backlog. The Test Platform package on NuGet is cross-platform, but VSTest task currently does not support running.NET core tests. To run.NET core tests, use the 'dot net' task. Run Functional Tests and Deploy Test Agent tasks are now deprecated Last year, we started on the journey to. This was intended to address various pain points associated with using WinRM based Deploy Test Agent and Run Functional Tests tasks.
It also enables you to use the Visual Studio Test (VSTest) task for all your testing needs, including:. Unit tests. Functional (UI/non-UI) tests. MSTest based tests.
A Small Request Re: Version Numbers Free
Third party framework-based tests. Assembly-based test specification or running tests with Test Plan/Test Suite. Single agent test execution as well as distributing tests over multiple agents The unified agents approach also allows administrators to manage all machines that are used for CI/CD in a uniform manner. We have delivered several crucial pieces to enable this capability, including:. Agents can be. allows VSTest task to run without needing Visual Studio pre-installed. Both Build and Release definitions can be created with for each phase.
Automated test cases can be using the VSTest task With all the above now in place, we are ready to deprecate these two tasks. While existing definitions that use the deprecated tasks will continue to work, we encourage you to move to using VSTest to take advantage of continued enhancement over time. Filter large test results Over time test assets accrue, and large applications can easily grow to thousands of tests. Teams are looking for better ways to navigate through large sets of test results to be productive while identifying test failures, associated root cause, or ownership of issues. To enable this, we have added three new filters under Tests Tab in Build and Release as Test Name, Container (DLLs) and Owner (Container Owner). Identify flaky tests Sometimes tests are flaky - they fail on one run and pass on another without any changes.
Flaky tests can be frustrating and undermines confidence in test effectiveness - causing failures to be ignored and bugs to slip through. With this Update, we have deployed the first piece of a solution to help tackle the problem of flaky tests.
You can now configure the Visual Studio Test task to re-run failed tests. The test results then indicate which tests initially failed and then passed on re-run. Support for re-run of data driven and ordered tests are coming later. The Visual Studio Test task can be configured to control the maximum number of attempts to re-run failed tests and a threshold percentage for failures (e.g.
Only re-run tests if less than 20% of all tests failed) to avoid re-running tests in event of wide spread failures. Preview improvements and support for different log types generated by Visual Studio Test task We enhanced the VSTest task to publish logs generated by different kind of logging statements corresponding to standard output and standard error for failed tests. We have also improved the preview experience to support viewing text and log file formats, with capability to search in the log files. Wiki Wiki search You can search for your favorite Wiki pages by title or content right alongside code and work items. You can read more about in the Microsoft DevOps Blog. Print Wiki pages Wiki can be used for a variety of content.
Sometimes it can be useful to print content from Wiki to read in your spare time, add comments using pen and paper, or even share an offline PDF copy with those outside of your VSTS project. Now, simply click on the context menu of a page and select Print page. This feature was prioritized based on a. These are in addition to standard editing shortcuts such as Ctrl+B for bold, Ctrl+I for italics, Ctrl+K for linking etc. See the for more information. Rich markdown rendering in code repo markdown You can now create rich README.MD files in the code repositories. The markdown rendering of the MD files in code repositories now supports HTML tags, Block quotes, Emojis, image resizing, and mathematical formulas.
There is parity in in Wiki and MD files in code. Wiki supports mathematical formulas If your application deals with mathematical formulas and equations, you can now put them in Wiki using the. General Profile Cards There are multiple areas in TFS where information associated to a particular individual is shown, such as, but not limited to: pull requests created by an individual, and work items assigned to an individual.
However, there is limited information about the individual itself for you to gain complete context. The new Profile Card replaces the existing profile card in TFS. The updated profile card allows you to interact with and learn more about users within your TFS account. Through integrations with your default email and IM client, Active Directory (AD) users can send emails and start chats directly from the profile card. AD users can also see the organizational hierarchy within the profile card.
Profile cards can be activated within project home page - team members section, version control, work items and Wiki sections by clicking on the contact card icon, profile picture, or users name within comments.