adamralph / bau-nuget Goto Github PK
View Code? Open in Web Editor NEWA Bau plugin for running NuGet commands
License: MIT License
A Bau plugin for running NuGet commands
License: MIT License
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.
Spun off from #31
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")
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.
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.
NuGetCliDownloadCommandRequestBase
be folded down into NuGetCliRestoreCommandRequest
?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.
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
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.
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.
Removing the Core and CLI implementation code from the Tasks will improve organization and allow more more flexibility with respect to other refactoring issues.
Consider using the primary Bau repository for issues, etc...
Some of the tests in the unit test assembly do some pretty crazy stuff and should be placed into their own assembly.
Also the method NuGetCliLocatorFacts.InstallNuGetCli
should be extracted from NuGetCliLocatorFacts
.
Pretty please set the primary branch to dev (if that is what you are into). Hope to keep this similar to the other repositories.
Review and possibly Ralphactor the Bau.NuGet code.
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.
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
Spun off from #31
pack
.Properties(new { Configuration = "Release"})
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)))
A fresh checkout does not build using Bau.
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.
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:
NuGetExePathOverride
property if set and fail if it is wrong../.nuget/NuGet.exe
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?
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.