Open matthid opened 6 years ago
Better to improve the existing one than have two surely?
"replace the bootstrapper" - what does this mean?
It means the task doesn't run the bootstrapper on the agent because the task is downloading paket
cache paket on agent - this will probably be difficult (impossible?) to do since as far as I'm aware there's no way to keep the same physical agent across builds / releases.
While that is true, there is a task library api to cache tools between runs, maybe they use it for internal optimizations. But it definitely optimizes the scenario where you run your own agents.
that would be great - integrating that into the main task and just have it run "automatically" would be way better than having multiple tasks.
Yep that one is probably a no-brainer.
However, is investing the time worth it? What I have noticed is that the fake-task is already enough for the general use-case. It already does setup everything and you don't really need any paket task at all.
It means the task doesn't run the bootstrapper on the agent because the task is downloading paket
Nice to have this feature but is it really needed - with magic mode you just replace the bootstrapper to paket.exe
anyway?
While that is true, there is a task library api to cache tools between runs, maybe they use it for internal optimizations. But it definitely optimizes the scenario where you run your own agents.
When you run your own agent paket is cached on the machine anyway, so it just works.
However, is investing the time worth it? What I have noticed is that the fake-task is already enough for the general use-case. It already does setup everything and you don't really need any paket task at all.
What about people that don't use FAKE at all and just want to use Paket in isolation - I think having the separation and ability to choose one or the other is a good thing. Of course, we could also just say that if you use FAKE, then you don't need the Paket task at all?
What about people that don't use FAKE at all and just want to use Paket in isolation
Yep even in those scenarios I'm not sure a separate task gives any advantages: As paket is integrated in the dotnet build
process you can just use the "setup paket credential manager" task and run dotnet build
, why add another task if you might need the "setup" task anyway? So we are only really tasking about legacy project format then...
Description
To integrate better into Azure DevOps I think we need another paket task (or improve the existing one). Imho it should:
This simplifies the tasks to one.
Question is: