search

huserben / TfsExtensions

Extensions for TFS 2015+ such as custom Widgets (require TFS 2017) and Build Tasks
MIT License
45 stars 22 forks source link

Save resulting build ID in environment #15

Closed garuma closed 7 years ago

garuma commented 7 years ago

In addition to output-ing the build ID, save it somewhere in the environment so that subsequent task (e.g. retrieve an artifact the triggered build has produced) can query it.

Thanks!

huserben commented 7 years ago

Hi

how do you mean "somewhere in the environment". Do you have an concrete suggestion on where to save it?

garuma commented 7 years ago

Ideally it would be an environment variable which I assume you need to set from the Javascript code so that it's properly maintained when executing other tasks (assuming it's the same Node.js process that's used throughout to execute each step of the build definition).

Another possibility would be to write the value somewhere on disk in a known path (maybe an argument that's passed to the task).

One last possibility that's slightly outside the scope is to augment your task to also be able to retrieve the artifact produced by a build directly (an extra API call and download) but that would be more work.

huserben commented 7 years ago

The Task is (currently) based on a PowerShell script, not with JS. I tried it with a Process-Level environment variable, but then you are not able to retrieve it in the following tasks.

However, with a User-Level variable it worked. I like the variable approach more than writing to a known path. You see any negative impact it could have when using the user-level variable?

For extending the Task to directly retrieve artifacts, I think then we are quite specific for the use case. When using the environment variable, the users are free to do whatever he wants with it.

Any objections from your side or shall I extend it with the environment variable? :-)

garuma commented 7 years ago

However, with a User-Level variable it worked. I like the variable approach more than writing to a known path. You see any negative impact it could have when using the user-level variable?

I'm not entirely sure what's the difference between the two type of variables (process/user) but if it's easy to propagate the value to follow-up tasks I'm all for it.

For extending the Task to directly retrieve artifacts, I think then we are quite specific for the use case. When using the environment variable, the users are free to do whatever he wants with it.

Completely agree.

Thanks for looking into it!

huserben commented 7 years ago

As far as I got it, the process level variable will only be visible in scope of the process. The user level variable will be available after the process has ended, But I don't think that's an issue.

Ok, I'll try to check in the changes somewhen during tomorrow.

No problem, thanks for the feedback 👍

huserben commented 7 years ago

So I just uploaded a new version with the option to store the id's in a build variable. You can find the option under Advanced Configuration. In the Task Overview on the Marketplace I added the chapter "Store Build IDs in Environment Variable" which includes as well an example on how to fetch the variable for example in a PowerShell Script.

garuma commented 7 years ago

Awesome, sounds perfect. Thanks again!