New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tool Versioning #753

Closed
dbent opened this Issue Mar 12, 2016 · 13 comments

Comments

Projects
None yet
6 participants
@dbent
Copy link
Contributor

dbent commented Mar 12, 2016

To make sure builds are repeatable for all users and that upstream changes don't impact the build process I always peg tools to particular versions, e.g:

#tool nuget:?package=Foo.Bar.Baz&version=1.0.0

This works well except in one particular case. Assume upstream makes significant backwards-incompatible changes and I update the build to support those changes. In that case I'll bump the version number as necessary:

#tool nuget:?package=Foo.Bar.Baz&version=2.0.0

This will then work fine for fresh clones of the project, but for anyone updating an existing clone, the installed 1.0.0 version of the tool will persist. Thus their build will break until they delete the tools/Foo.Bar.Baz directory to force an update to 2.0.0

An "easy" solution would be to add the version to the directory so that instead of just tools/Foo.Bar.Baz you would have tools/Foo.Bar.Baz.1.0.0 and tools/Foo.Bar.Baz.2.0.0. However, that complicates resolving which tool to use if multiple copies may exist. #736 may be relevant here.

Thoughts?

@patriksvensson

This comment has been minimized.

Copy link
Member

patriksvensson commented Mar 13, 2016

@dbent Yes, this need to be done in #736 as you mention for things to work reliably. Just changing the name of the folders would randomize what version that will be used as it is now.

I've started working on it here but it's not ready yet, but folder version support will be added as well once ready.

@robertcoltheart

This comment has been minimized.

Copy link
Contributor

robertcoltheart commented May 9, 2016

The .nupkg files are preserved when they are downloaded to Tools aren't they? Why not use the version of the nupkg to see whether they need to be updated or not as compared to the packages.config?

Edit: Just realised this is probably due to a bug in NuGet rather than in Cake: NuGet/Home#2405

@saasen

This comment has been minimized.

Copy link

saasen commented Dec 1, 2016

When running cake on our build server (TeamCity), it's as @dbent says. Since the folders or tools are not versioned, it will not download the latest tool when changing the version of a tool directive. This could be solved by cleaning the directory completely, but it would slow down builds a lot.

@robertcoltheart

This comment has been minimized.

Copy link
Contributor

robertcoltheart commented Dec 1, 2016

@saasen This is solved by putting tool dependencies in the packages.config and using the latest bootstrapper from here. Changes to the packages.config and now MD5 checked and tools and re-downloaded if the versions change.

@saasen

This comment has been minimized.

Copy link

saasen commented Dec 1, 2016

Thanks a lot @robertcoltheart. I'll try that.

@saasen

This comment has been minimized.

Copy link

saasen commented Dec 2, 2016

@robertcoltheart: I've played around with this, and it seems like I can't get it to work. Let me explain.

Here's the old way of setting up tools and addins in build.cake:

#tool "nuget:https://www.nuget.org/api/v2?package=xunit.runner.console"
#tool "nuget:https://www.nuget.org/api/v2?package=OctopusTools&version=3.5.4"
#tool "nuget:https://www.nuget.org/api/v2?package=ReportGenerator"
#addin "nuget:https://www.nuget.org/api/v2?package=Cake.Powershell"
#addin Cake.Chutzpah https://www.myget.org/F/extra-build-packages/api/v2

Here's my new packages.config file:

<?xml version="1.0" encoding="utf-8"?>
<packages>
	<package id="Cake" version="0.17.0" />
	<package id="Cake.Chutzpah" version="0.0.3" />
	<package id="Cake.Powershell" version="0.2.7" />
	<package id="OctopusTools" version="3.5.4" />
	<package id="ReportGenerator" version="2.5.1" />
	<package id="xunit.runner.console" version="2.1.0" />
</packages>

It seems like when I remove the directives from the cake script, everything stops working. It can't find any tools and addins. My guess is we still need the tools and addins directives for Cake to understand we need these tools. It can't understand what we need just from reading the packages.config file, right? How do you set this up?

Also, we have some custom NuGet feeds we need to add. In this case, this is for Cake.Chutzpah. We can use the nuget.config approach here I guess, since Cake supports NuGet by default.

I can't see what I'm doing wrong? Do the tool and addin directives need to link to a file instead of a NuGet source now?

@gep13

This comment has been minimized.

Copy link
Member

gep13 commented Dec 2, 2016

@robertcoltheart the packages.config file is only intended to resolve tools that are used by Cake, not for addins. Addins would still need to be resolved using the pre-processor directive, as you were doing before.

@saasen

This comment has been minimized.

Copy link

saasen commented Dec 5, 2016

@gep13: Do you know if there will be any support for versioning of addins, much like tools?

@gep13

This comment has been minimized.

Copy link
Member

gep13 commented Dec 5, 2016

@saasen going forward, I think the recommendation would be that all tools and addins will be consumed using the preprocessor directives. The difference being that the preprocessor will understand how to request the specific version, and handles upgrades correctly. There is an open issue about this in the 0.18.0 milestone

@saasen

This comment has been minimized.

Copy link

saasen commented Dec 5, 2016

Sounds good. Looking forward already!

@saasen

This comment has been minimized.

Copy link

saasen commented Mar 17, 2017

@gep13: Which issue were you referring to? I didn't see anything about this in the 0.18 release notes.

@gep13

This comment has been minimized.

Copy link
Member

gep13 commented Mar 17, 2017

@saasen this was the issue that I was referring to: #787 but it got bumped from 0.18.0 to 0.19.0.

@mholo65

This comment has been minimized.

Copy link
Member

mholo65 commented Aug 7, 2017

Solved by #1706

@mholo65 mholo65 closed this Aug 7, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment