9

I get a 409 Conflict for my VSO build definition that packages and publishes to a VSO feed.

So each build run is a failure.

VSO build error

However, the package ends up in the feed.

VSO feed good

Any clue? Thanks.

Daniel Mann
  • 57,011
  • 13
  • 100
  • 120
Luke Puplett
  • 42,091
  • 47
  • 181
  • 266

2 Answers2

6

The error message you see is usually caused by that the VSO feed already has the package which has the same name and version number as the one your are publishing. But according to the second screenshot, the package is been published during the build process. So I'm wondering if the package is published twice during the process. You need to check your build definition to see if the package is been published twice during the build or there are two build definitions doing the same thing at the same time.

Update: You can set "Automatic package versioning" to "Use the build number" and set "Build number format" to "1.2$(Rev:.r)" so that the nuget package version will be 1.2.* and increase after each build. enter image description here

Eddie Chen - MSFT
  • 29,708
  • 2
  • 46
  • 60
  • 1
    Hi Eddie, I like your thinking. It's a good theory. Sadly, I've deleted the definition and gone back to manual build and publish from my desk (this is a personal project). This was in part because the builds queue for >30 mins sometimes, and I can't wait that long to update a library and continue working on the main project. – Luke Puplett Apr 21 '16 at 10:40
  • @LukePuplett Did you increase the nuget package version when you build and publish it from your desk? – Eddie Chen - MSFT Apr 22 '16 at 03:21
  • Definately always upp'ed the version number. I was aware that a 409 was a version conflict from setting up VSO NuGet feeds at work. Btw, I was really hoping to be able to just use 1.2.* in the version attribute and that VSO build would just build with an auto stamp and push it, but found that VSO build doesn't support it, see link, which was another factor for not pursuing using VSO build. I need to crack on these days, I get too caught up in solving problems in new tech. http://stackoverflow.com/questions/36630381/vso-build-the-replacement-token-version-has-no-value/36630382#36630382 – Luke Puplett Apr 23 '16 at 11:29
  • @LukePuplett Another thing to check: What build agent are you using, Hosted Build Agent or your own build agent? And if you are using your own build agent, did you delete the nuget packages generated by last build before run the next build? If not, the nuget publisher task will publish the old packages which will also cause 409 error. For the version arrtibute, please refer to the information in my answer for details. – Eddie Chen - MSFT Apr 25 '16 at 03:19
  • I might set it all up again when I get time one day and I'll check all this. Thanks for the version format, I'll mark as answer for now. – Luke Puplett Apr 30 '16 at 09:21
  • Howdy. I was having this same issue, just needed to remove the old packages from the source dir before each build. – Sam Sep 13 '16 at 01:01
5

I was having this same problem. The solution is to add a step at the start of your build that deletes the old .nupkg files. Super easy...

  1. Add delete files step.
  2. Move to start of build.
  3. Set source folder= $(Build.Repository.LocalPath)
  4. Set contents = *.nupkg
  5. Enjoy your new green builds.
Sam
  • 7,543
  • 7
  • 48
  • 62
  • Hey Sam, thanks for answer. The problem with this is that you may need the full history of packages for all the branches - some devs working on an branch taken from weeks ago - and when/if you ever need to rollback a deployment or go back and run an old version of an app as it was, maybe to debug a regression that you think crept in some months back. – Luke Puplett Sep 14 '16 at 21:11
  • I see. Devs would get the old package from the build server? I'm new at this, so maybe a silly question. The package would be on the deploy server as well. – Sam Sep 19 '16 at 17:58
  • Yeah all your versions of the package would be on your NuGet server, not forever, but for a good while. Obviously it depends on your situation and project. If you have a large team and many projects each with many branches, you could be referencing 20 different versions of a nupkg. – Luke Puplett Sep 20 '16 at 20:38
  • +1 for the answer, didn't even think about this.No one should ever be pulling files off the build server, period. – EKW Jul 15 '17 at 02:06
  • my files are not getting deleted by following your instructions, any advice on how to debug this? – Andrey Apr 16 '18 at 20:00
  • @EKW, that's ridiculous, the build server should be building clean from source control every time (which is the default)!! -- You definitely do not want files from old builds hanging around and giving you non-deterministic build outputs! – BrainSlugs83 Jun 05 '18 at 23:52
  • @BrainSlugs83 I didn't say any of that. Did you mean to reply to a different comment? – EKW Jun 06 '18 at 17:03