adamralph / bau-nuget

A Bau plugin for running NuGet commands

Hi there 👋

bau-nuget's Issues

CI build

Either http://teamcity.codebetter.com/ or https://ci.appveyor.com/. We could also try for a Mono build on https://travis-ci.org/ but I'm not sure how well NuGet.exe plays on *nix these days.

• appveyor
• travisci

Some tests should be broken apart from unit tests.

Some of the tests in the unit test assembly do some pretty crazy stuff and should be placed into their own assembly.

• NuGetCliLocatorFacts
• NuGetPackFacts
• NuGetPushFacts
• NuGetRestoreFacts

Also the method NuGetCliLocatorFacts.InstallNuGetCli should be extracted from NuGetCliLocatorFacts.

fix build for scriptcs 0.13

Fails due to scriptcs/scriptcs#912, which can be worked around by running scriptcs -install separately before scriptcs ./baufile.csx.

Also fails because baufile.csx is looking in packages/ instead of scriptcs_packages.

*nix build needs to change to download a new blob. The one it is using is based on scriptcs 0.10.

consider removing issues from this repository

Consider using the primary Bau repository for issues, etc...

parallel operations

If the new API works out making the operations parallel is super easy. Would there be any reason to perform these operations in parallel using .InParallel() for example? It could increase performance for things like push when there are symbol files but it could add a lot of safety issues. For example what if the first push fails, should the second also be attempted? If two pushes happen at the same time will the server ignore one of the requests? Without any kind of retry mechanism it probably is not safe enough to provide such a feature. Also if retries are common the performance gains would be lost.

Better verbosity API

Spun off from #20.

Currently, due to a clash with BauMSBuild.Verbosity, it's necessary to fully qualify the type, e.g.

.WithVerbosity(BauNuGet.Verbosity.Detailed)

Suggestions:

.WithVerbosity(NuGetVerbosity.Detailed)
.WithVerbosity("detailed")

Use the new nuget

A reference to Bau.NuGet should be added to ./packages.config for both baufile.csx and dog.csx to use. Also if we are comfortable enough with it we can use the NuGet task for the baufile.csx builds.

With(params string[] args)

Spun off from #31

Primary branch: dev

Pretty please set the primary branch to dev (if that is what you are into). Hope to keep this similar to the other repositories.

ambiguous reference in dog food script :dog:

The dog.csx script has an ambiguous reference:

ERROR: dog.csx(3,57): error CS0104: 'Verbosity' is an ambiguous reference between 'BauMSBuild.Verbosity' and 'BauNuGet.Verbosity'

Broken by: 48745e6

Use NuGet.exe exclusively

We shouldn't be using NuGet.Core for some things and NuGet.exe for others. We should be using one or the other. I'm preferring NuGet.exe so that at some point we can allow flexibility with the target and people can use their own installations on PATH, etc.

Improved fluent API

The current fluent API does not match the style using in existing core plugins such as the Xunit plugin. The nuget plugin uses a form similar to WithSomeProperty(theValue) while Xunit uses SomeProperty(theValue). The fluent API within the NuGet plugin should do the same.

Also the API should be able to handle multiple files without needing to use lambdas. Currently the fluent API requires application with a lambda to apply to multiple commands. It would be much better if the API could operate on a list of commands.

nuget
.Pack(pack + ".csproj")
.Output(output)
.Properties(new { Configuration = "Release"})
.IncludeReferencedProjects()
.Verbosity(nugetVerbosity)
.Version(version + versionSuffix)))

Cannot execute NuGet.exe on Mono

It looks like a path problem. The absolute path is resolved to /home/... on Mono and the .NET runtime can't find it when starting the process.

BauNuGet.Test.Unit.PushFacts.Pushes [FAIL]
System.ComponentModel.Win32Exception : ApplicationName='/home/travis/build/bau-build/bau-nuget/src/packages/NuGet.CommandLine.2.8.3/tools/NuGet.exe', CommandLine='push /home/travis/build/bau-build/bau-nuget/src/packages/NuGet.CommandLine.2.8.3/NuGet.CommandLine.2.8.3.nupkg -Source "/home/travis/build/bau-build/bau-nuget/src/test/Bau.NuGet.Test.Unit/bin/Release/fake NuGet dot org/" poop -Timeout 123 -NonInteractive', CurrentDirectory='./', Native error= Cannot find the specified file

Extract task execution logic from NuGetBauTaskBase and children.

Removing the Core and CLI implementation code from the Tasks will improve organization and allow more more flexibility with respect to other refactoring issues.

Support multiple requests.

The current implementation only supports one NuGet operation per BauTask. The fluent interface as well as the Task implementations should be rearrange to support this.

.NuGetPack("pack").DependsOn("build", "clobber", "output").Do(nuget => nuget
    .For("file1.nuspec", "file2.csproj", "file3.nuspec") // IEnuerable<string>
    .WithOutputDirectory(output)
    .WithProperty("Configuration","Release")
    .WithIncludeReferencedProjects()
    .WithVerbosity(nugetVerbosity)
    .WithVersion(version + versionSuffix))

My current thoughts are that after #5 is complete a NuGetBauTaskBase would just store a collection of requests that would all be executed in the BauTask OnActionsExecuted()

The For() method (likely an extension method) would need to accept IEnumerable<string> as well as params string[]. For each target file a request would be created, queued with the task and then returned for use with fluent operations.

Initial code review of the project

Review and possibly Ralphactor the Bau.NuGet code.

Remove dependency on specific scriptcs configuration for tests to pass

Collapse type hierarchy

• Can NuGetCliDownloadCommandRequestBase be folded down into NuGetCliRestoreCommandRequest?
• Can NuGetCliBauTaskBase be folded down into NuGetCliBauTaskBase<TRequest>?

At the moment, in each of those cases there is a single inheritor so it seems they can be collapsed, in the name of YAGNI.

Where's NuGet?

Right now NuGet.exe is located by finding a packages folder containing NuGet.exe by incrementally searching down from the current directory. So far this is OK as it Works for Me but it may be an issue in the future when others start to use the plugin.

The NuGet search algorithm should probably be changed to something closer to this:

1. Use the NuGetExePathOverride property if set and fail if it is wrong.
2. Search towards root from {some directory} until it is found as a package
3. While searching, keep an eye out for ./.nuget/NuGet.exe
4. See if it is on the PATH.

Sometimes the search makes sense from current directory while in other situations the current directory may have been modified or the script may have been run from an unrelated working directory. In those cases searching down from the "packages" directory containing Bau.NuGet.dll may be a valid solution as well. Maybe both methods should be used, but in what order?

Sever dependency on Bau.Exec

We shouldn't be referencing Bau.Exec. There is an extension method in BauCore for ProcessStartInfo and we should use that instead for executing a command line app.

fix appveyor build status reporting on PRs

Doesn't seem to be working, e.g.

Fix Bau build

A fresh checkout does not build using Bau.

Pack.Properties(object)

Spun off from #31

pack
    .Properties(new { Configuration = "Release"})