Only download artifacts required for task execution
Please add a configuration option for a release definition to force agents to only download artifacts that are required for task execution.
Currently, all artifacts are downloaded. For large releases, this could be hundreds of megs or even GBs. If my release def only uses 1 artifact, only that artifact should be downloaded.
We are happy to let you know that your suggestion is now available on Team Services . It will become available to the on-prem version in TFS 2018 Update 2.
Daniil Marchenko commented
Feature has actually not been enabled to to a bug. Se more here: https://developercommunity.visualstudio.com/content/problem/227427/tfs-2018-update-2-rc-select-artifacts-to-download.html
Stoyan Penchev commented
Will this feature ever be enabled? It's been months
Not available in TFS2018 Update2
Not in TFS2018 Update2.
Michael Ayvazyan commented
We are waiting for this one as well. It's not available in Update 2.
Philip Reed commented
Can someone give an update on this feature, It doesn't appear to have been included in Update 2.
No sign of this feature in TFS 2018 Update 2. Will we have to wait until 2019 ?
This feature was missed in the TFS 2018 Update 2 RC 1, will this make it into the final release for Update 2?
Any update for this feature? I generated different artifacts for release, but one phase only needs one of the artifacts. Downloading all artifacts is really painful and wasting time.
Further to this we need to able to select a specific folder from the artifact, this is required because I've one artifact generated from solution and deployment happens in two phases 1st phase in which I'll deploy web app (This happens through deployment group) and DB deployment happens through on-premise agent to Azure SQL DB but all the artifact gets download but I only require dacpac project folder to be selected
Lukas Grützmacher commented
It would be really helpful to have filtering options on artifact download for each agent!
Vincent Adams commented
Is there a planned release date for this feature yet? I know we can use the vsts extension but would rather use something built into vsts.
Also need ability to configure the agent phase with which artifacts to download. Currently our artifacts amount to ~500MB per release, and each agent phase would only need 100MB of that.
This would be a massive savings in time and cost of bandwidth. Please add a robust implementation.
I have the exact same issue. Not a blocking - but I would reduce the time of each environment's release, when I know for a fact that I'm in Dev environment and I will be only needing Dev artifacts generated by the current build.
This could really be helpful.
Thanks - Rikki.
I'm not sure that would work well. We have dozens of definitions.
I'm thinking more of a scan during the download artifacts stage that checks the paths used in the following steps to determine what artifacts are used.
Like when we run tests on multiple agents I don't want every agent to download all artifacts for the project, but just the testing framework.
If we'd need to manually set those for every environment we'd probably just let it download everything as the overhead would not be worth it.
Perhaps a small alternative would be to be able to exclude the download of specific artifacts for specific environments and/or phases.
Greg Pakes commented
There is already an extension for this: https://marketplace.visualstudio.com/items?itemName=chamindac.chamindac-vsts-release-task-download-artifacts
When reading the documentation it is mentioned that you can skip the artifact download for a phase and then ''write your own tasks that perform a more optimized download process".
Would be nice if we could specify filter(s) out of the box when it comes to the artifact download.
Brian Harvey commented
We are attempting a build once practice; however, due to the nature of our many clickonce deployed applications we are required to build and publish the artifacts for all regions and all clients (SAAS). This results in gigabytes of files that have to be downloaded for each release, even though as many have said we only need specific items. Perhaps if there was the ability to indicate directories within a published artifact location that we want to download for a given release.
For example, when we build we output the following under a given artifact build for 1 of the 12 components for our application: DEV, TEST01, TEST02, UAT-client1, UATclientx..., PROD-client1, PROD-clientx....
If we are releasing to test, I do not need to download all of the directories under the published artifact for UAT and PROD.
We really need this ability!!!!
I like this idea... we have similar issues too with this.
Couple of our builds are rather large and have a lot of Artifacts associated with them which get stored in TFS (Server), but hardly any will be used in the Release.
Seems good to store them in TFS as part of the Build but we certainly don't need to download all of them within in a Release. It pushes the Release time up considerably whilst waiting for them to download, having no control over which ones are downloaded is a shame.
Perhaps a simple list and tick boxes next to any you would like to download from the last drop location would be an idea... if the 'Download Artifacts' task was available to be modified as part of the Release definition?
Ben Houghton commented
This would be great for things like documentation. We have a single build that creates all of the assemblies, tests and documentation for each change that is pushed to the main branch. The view being that once it's been built then these are the assemblies that are tested and promoted though to produciton.
The publishing of the documentation is done though a release to the documentation "environment" which in turn is triggered after tests have successfully been run on our QA environment. However the documentaion is downloaded as part of the artifact on all environments, despite it not being needed, so all it does is slow down the overall process. I know that I could probably add steps to generate the documentaion as part of the release definition, but adding build steps to a release definition doesn't seem like a good idea.