(re-) implement Paket Task

isaacabraham / vsts-fsharp

Azure Devops extension for F#-friendly tools

https://marketplace.visualstudio.com/items?itemName=isaacabraham.fsharp-helpers-extension

Apache License 2.0

13 stars 7 forks source link

(re-) implement Paket Task #26

Open matthid opened 5 years ago

matthid commented 5 years ago

Description

To integrate better into Azure DevOps I think we need another paket task (or improve the existing one). Imho it should:

do what the paket.bootstrapper does / replace the bootstrapper
cache the paket tool on the agent (similar to how the fake task caches fake)
automatically setup and clear the paket credential manager

This simplifies the tasks to one.

Question is:

Does it make sense?
Is the fake task enough anyway?

isaacabraham commented 5 years ago

Better to improve the existing one than have two surely?

"replace the bootstrapper" - what does this mean?
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. The only way to do this as far as I know (and we've done this) is to host our own VM and install the ADO build agent on it.
credential manager - that would be great - integrating that into the main task and just have it run "automatically" would be way better than having multiple tasks.

matthid commented 5 years ago

"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.

isaacabraham commented 5 years ago

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?

matthid commented 5 years ago

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...