Hello everyone, Writing on behalf of SymbolSource - we are aware of our timeout issue, and we will fix it. This goes a bit deeper, though, into nuget.exe not expecting push operation to have any kind of longer processing on the server, and will need to coordinate our improvements with the NuGet Team.
Can you set the build scripts to ignore errors coming from nuget push *.symbols.nupkg for now? That is push the regular package normally and the symbols package separately without failing the build if it goes wrong? The thing is that, even though nuget.exe times out, we still finish processing the symbols and sources on the server side. It times out only *after* completing the upload. Best regards, Marcin (TripleEmcoder) On Thu, May 24, 2012 at 12:08 PM, Diego Mijelshon <[email protected]>wrote: > As long as the timeouts can be solved, the symbols are always useful... > > Diego > > On Thu, May 24, 2012 at 1:23 AM, Julian Maughan > <[email protected]>wrote: > >> It would certainly be good to automate the build of the NuGet package on >> the CI server - whether or not its published doesn't bother me. >> >> Would we want to deploy the symbols as well? Reason I ask is that there >> have been difficulties (timeouts) uploading them. >> >> >> On 24 May 2012 03:57, Diego Mijelshon <[email protected]> wrote: >> >>> Zeroes is probably best. But we'd have to try. >>> >>> >>> On Wed, May 23, 2012 at 4:48 PM, Stephen Bohlen <[email protected]>wrote: >>> >>>> I guess so long as its also a separate package from the release package >>>> this might be feasible. So we'd have something like... >>>> >>>> NHibernate-AutomatedBuild.2012.0523.1545.nupkg (May 23rd, 2012 at 15:45) >>>> NHibernate-AutomatedBuild.2012.0524.0822.nupkg (May 24th, 2012 at 08:22) >>>> >>>> It begs the question though: what version do you stamp the actually >>>> assembly with? 0.0.0? Or one of the above (2012.0524.0822)? >>>> >>>> >>>> >>>> Steve Bohlen >>>> [email protected] >>>> http://blog.unhandled-exceptions.com >>>> http://twitter.com/sbohlen >>>> >>>> >>>> On Wed, May 23, 2012 at 3:13 PM, Diego Mijelshon < >>>> [email protected]> wrote: >>>> >>>>> Yes, that's what I meant. 0.0.0 might work... or we could use YYYY as >>>>> major, MMDD as minor, HHMMSS as revision... or anything else. >>>>> It really doesn't matter much, as the idea is to use whatever is the >>>>> latest successful build. >>>>> >>>>> Diego >>>>> >>>>> >>>>> On Wed, May 23, 2012 at 4:10 PM, Stephen Bohlen <[email protected]>wrote: >>>>> >>>>>> Sorry I think I misunderstood your point -- I just reread your >>>>>> message. So you mean that we don't need the 3.0.0 part and could just do >>>>>> the YYYYMMDDHHMMSS part of the version? >>>>>> >>>>>> I suppose this might work, but then we'd need to have *something* in >>>>>> the version slots to make NuGet happy (e.g., at least 0.0.0) else I don't >>>>>> think its version-composing algorithm will work properly. >>>>>> >>>>>> Was that more what you meant...? >>>>>> >>>>>> -Steve B. >>>>>> On May 23, 2012 2:04 PM, "Stephen Bohlen" <[email protected]> wrote: >>>>>> >>>>>>> No? Since you can't replace the contents of an existing NuGet >>>>>>> package without increasing its version number, how would that work? How >>>>>>> would you distinguish the latest automated build result from the one 10 >>>>>>> minutes prior? >>>>>>> >>>>>>> Are you envisioning that we would script the complete removal of the >>>>>>> existing package and then post a brand new package named/versioned >>>>>>> identically to the one just deleted? And if a don't increment the >>>>>>> version, >>>>>>> clients doing an update operation to get latest won't see anything new >>>>>>> because NuGet depends on version-comparisons to work, no? >>>>>>> >>>>>>> -Steve B. >>>>>>> On May 23, 2012 1:59 PM, "Diego Mijelshon" <[email protected]> >>>>>>> wrote: >>>>>>> >>>>>>>> You don't even need the version part. It's just continuous delivery. >>>>>>>> >>>>>>>> Diego >>>>>>>> >>>>>>>> On Wed, May 23, 2012 at 3:23 PM, Stephen Bohlen >>>>>>>> <[email protected]>wrote: >>>>>>>> >>>>>>>>> So were leaning towards something like.... >>>>>>>>> >>>>>>>>> NHibernate-AutomatedBuild.3.0.0-YYYYMMDDHHMMSS.nupkg >>>>>>>>> >>>>>>>>> ...so we can ensure both uniqueness and proper version sort order >>>>>>>>> (assumes impossible to build twice in the same second!). Is that >>>>>>>>> right...? >>>>>>>>> >>>>>>>>> -Steve B. >>>>>>>>> On May 23, 2012 1:18 PM, "Diego Mijelshon" <[email protected]> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> A separate feed is what Microsoft itself is doing with MVC4 (see >>>>>>>>>> http://blogs.msdn.com/b/henrikn/archive/2012/04/29/using-nightly-nuget-packages-with-asp-net-web-stack.aspx >>>>>>>>>> ) >>>>>>>>>> >>>>>>>>>> I personally think using a separate package is enough, although >>>>>>>>>> naming should be done carefully. NHibernate-CI might not be enough >>>>>>>>>> for >>>>>>>>>> everyone. >>>>>>>>>> >>>>>>>>>> Other than that, I really like the idea. >>>>>>>>>> >>>>>>>>>> Diego >>>>>>>>>> >>>>>>>>>> On Wed, May 23, 2012 at 12:17 PM, Stephen Bohlen < >>>>>>>>>> [email protected]> wrote: >>>>>>>>>> >>>>>>>>>>> There seems to be little if any consensus about the 'right' way >>>>>>>>>>> to do this. NuGet now does support the idea of pre-release >>>>>>>>>>> packages (e.g. >>>>>>>>>>> something like 3.0.0-alpha as version number) and the ability to >>>>>>>>>>> filter >>>>>>>>>>> these IN or OUT of the search results in the NuGet client dialog >>>>>>>>>>> but the >>>>>>>>>>> idea of every CI build showing up as a pre-release version of the >>>>>>>>>>> same NH >>>>>>>>>>> package that would eventually become the release has some >>>>>>>>>>> challenges: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 1. pre-release packages use alpha-numeric sorting to >>>>>>>>>>> determine 'latest' by version so while 3.0.0-beta would be >>>>>>>>>>> properly newer >>>>>>>>>>> than 3.0.0-alpha (since B after A), determining a suffix for >>>>>>>>>>> *every* CI >>>>>>>>>>> build that ensures that the proper 'latest' pre-release is >>>>>>>>>>> always seen by >>>>>>>>>>> nuget as 'latest' isn't trivial (we could do something like >>>>>>>>>>> 3.0.0-ci-000001, 3.0.0-ci-000002, 3.0.0-ci-000003, etc. but >>>>>>>>>>> that's probably >>>>>>>>>>> a bit obtuse for people to understand what's going on and in any >>>>>>>>>>> case we'd >>>>>>>>>>> quickly run out of digits unless we did something silly like >>>>>>>>>>> 3.0.0-ci-0000000000000000000000000000001 ) >>>>>>>>>>> 2. IMO there is (probably) a difference betw. a) people who >>>>>>>>>>> will only want to use the official release, b) people who are >>>>>>>>>>> willing to >>>>>>>>>>> use 'official pre-release milestones' like alpha, beta, >>>>>>>>>>> whatever, and c) >>>>>>>>>>> people who really want to live on the bleeding edge of 'every CI >>>>>>>>>>> build'. >>>>>>>>>>> NuGet's pre-release versioning strategy distinguishes betw. a) >>>>>>>>>>> and b) but >>>>>>>>>>> NOT betw. b) and c). "Muddying" the distinction betw. b) and c) >>>>>>>>>>> for us >>>>>>>>>>> would mean that it would no longer be possible to use nuget's >>>>>>>>>>> pre-release >>>>>>>>>>> versioning to actually release something like 3.0.0-alpha and >>>>>>>>>>> have it >>>>>>>>>>> appear as 'latest pre-release' b/c it wouldn't be 'after >>>>>>>>>>> 3.0.0-ci-0000X. >>>>>>>>>>> Creatively considering the suffixing strategy might permit this >>>>>>>>>>> to still >>>>>>>>>>> work, but its non-trivial to reason through. Worse, even if we >>>>>>>>>>> were to do >>>>>>>>>>> something clever with suffixes that solved this problem we'd >>>>>>>>>>> need to >>>>>>>>>>> consider how to handle the situation where we put out >>>>>>>>>>> 3.0.0.-special-suffix-for-beta and then someone commits and the >>>>>>>>>>> CI process >>>>>>>>>>> publishes something that suddenly appears LATER than >>>>>>>>>>> 3.0.0-special-suffx-for-beta. This would make it more >>>>>>>>>>> challenging for >>>>>>>>>>> those seeking the beta to find it since it wouldn't any longer >>>>>>>>>>> be 'latest'. >>>>>>>>>>> >>>>>>>>>>> All of these limitations re: the design/impl of nuget's >>>>>>>>>>> pre-release versioning scheme lead me to conclude that using it for >>>>>>>>>>> CI >>>>>>>>>>> builds is too much of a problem (both for package authors and for >>>>>>>>>>> package >>>>>>>>>>> consumers). FWIW, I've done considerable investigation into this >>>>>>>>>>> in the >>>>>>>>>>> context of other OSS projects with CI builds and have concluded >>>>>>>>>>> that the >>>>>>>>>>> only feasible strategy for publishing CI-build-based packages to >>>>>>>>>>> nuget is >>>>>>>>>>> one of the following: >>>>>>>>>>> >>>>>>>>>>> 1. Create your own sep. NuGet feed (either self-hosted or >>>>>>>>>>> something like myget.org) and post CI-build-based packages >>>>>>>>>>> there; those that want 'bleeding edge' add this second feed to >>>>>>>>>>> their nuget >>>>>>>>>>> client; those that don't can still distinguish betw. pre-release >>>>>>>>>>> milestone >>>>>>>>>>> versions (alpha, beta, etc.) and actual release versions in the >>>>>>>>>>> main nuget >>>>>>>>>>> feed >>>>>>>>>>> 2. Create a completely separate package entirely (e.g., >>>>>>>>>>> NHibernate-CI.nupkg vs. NHibernate.nupkg) that represents the >>>>>>>>>>> CI-build-based content and still push this 'second' package to >>>>>>>>>>> the main >>>>>>>>>>> nuget feed. >>>>>>>>>>> >>>>>>>>>>> #1 is less discoverable but since you can filter by nuget feed >>>>>>>>>>> source in the Nuget dialog box its then possible for a consumer to >>>>>>>>>>> explicitly select the CI-only feed when they want to add/update the >>>>>>>>>>> package >>>>>>>>>>> based on CI build and then select the main nuget feed only when >>>>>>>>>>> they want >>>>>>>>>>> to see either/or pre-release milestone packages or the final release >>>>>>>>>>> packages. >>>>>>>>>>> >>>>>>>>>>> #2 is more discoverable since its in the main feed (and would >>>>>>>>>>> presumably contain the name 'NHibernate' as part of its package >>>>>>>>>>> name so it >>>>>>>>>>> would appear in the search results) but it has another challenge: >>>>>>>>>>> if its a >>>>>>>>>>> DIFFERENT package entirely, then when the main package goes 'GA' >>>>>>>>>>> (release) >>>>>>>>>>> consumers of the NHibernate-CI package will have NO WAY OF KNOWING >>>>>>>>>>> b/c they >>>>>>>>>>> won't be using the main NHibernate.nupkg in their projects at that >>>>>>>>>>> point >>>>>>>>>>> (and doing a nuget-update-packages won't pull down the 'official >>>>>>>>>>> release' >>>>>>>>>>> at that point b/c they aren't using that actual package at all). >>>>>>>>>>> >>>>>>>>>>> If there are other ideas about the best way to handle this, then >>>>>>>>>>> I am *absolutely* interested in hearing about them since this is a >>>>>>>>>>> non-trivial set of issues to grapple with and I continue to seek >>>>>>>>>>> the best >>>>>>>>>>> possible approach that might be out there (for NH as well as other >>>>>>>>>>> .NET OSS >>>>>>>>>>> projects that have this exact same set of challenges to exposing >>>>>>>>>>> their CI >>>>>>>>>>> builds as NuGet packages). >>>>>>>>>>> >>>>>>>>>>> Regards, >>>>>>>>>>> Steve Bohlen >>>>>>>>>>> [email protected] >>>>>>>>>>> http://blog.unhandled-exceptions.com >>>>>>>>>>> http://twitter.com/sbohlen >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Wed, May 23, 2012 at 10:30 AM, Alexander I. Zaytsev < >>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>> >>>>>>>>>>>> Hi all. >>>>>>>>>>>> >>>>>>>>>>>> I think that it would be greate if our CI-builds would be >>>>>>>>>>>> available at the nuget. >>>>>>>>>>>> >>>>>>>>>>>> What do you think? >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>> >>>> >>> >> >
