zarro 1.92.0

package/LICENSE

@@ -0,0 +1,10 @@
+Copyright (c) 2013, Davyd McColl. All rights reserved.
+
+Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:
+
+    1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
+    2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
+    3. Neither the name of the copyright holder nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission.
+
+THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+

package/README.md

@@ -0,0 +1,260 @@
+# Zarro
+![Test](https://github.com/fluffynuts/zarro/workflows/Tests/badge.svg)
+
+![npm](https://img.shields.io/npm/v/zarro)
+
+## What is this?
+
+Standing on the shoulders of giants, zarro is a zero- or low-conf orchestration for
+(primarily) dotnet/.NET build and test (eg at CI), but it's also so much more - since
+it's easy to add your own tasks, you can use zarro for whatever you like, but if you're
+looking for CI build / test / coverage* for dotnet/.NET, this might be what you're looking
+for.
+
+_(* coverage works well for NUnit / .NET Framework, but I haven't found a nice process
+for dotnet core - yet)_
+
+## Why not just use `msbuild`?
+
+Zarro wraps msbuild, using `gulp` orchestration under the hood. It does, however,
+take away the pain of:
+- knowing _where_ msbuild lives (since it consumes [gulp-msbuild](https://www.npmjs.com/package/gulp-msbuild)
+- being able to use a specific version of msbuild (again, thanks to `gulp-msbuild`)
+- running tests via `dotnet test` or via the NUnit CLI runner, as appropriate
+- running coverage reporting (.NET Framework) via OpenCover
+- downloading local variants of tooling required for the above so that your CI server
+  doesn't have to have them installed, or kept up to date
+    - note: zarro will not download msbuild tooling, but should work fine with any
+        installed version of:
+        - VS Community / Professional / Enterprise
+        - VS Build Tools
+        - dotnet sdk (dotnet kindly adds itself to the path)
+- packing nuget packages, either from .nuspecs (.NET Framework) or directly
+  from the .csproj (dotnet core)
+
+## Fine, but I can do all of that with a batch file?
+
+Perhaps (though the msbuild discovery is a bit of a PITA, especially since Microsoft
+likes to keep us on our toes, mixing up exactly _where_ that's installed to, eg in
+vs2019. The real win comes from:
+- out of the box, on a simple-ish repo, zarro should be able to build and test,
+  as long as you use the naming convention of `{Assembly}.Tests` for test projects
+  (though it will also find `Test.{Assembly}` and an ubiquitous `Tests` assembluy)
+- it's easy to add more tasks to your pipeline for further processing
+- use the `gulp` orchestration framework to extend or override available tasks
+
+## _Which_ `gulp`? 3 or 4? They don't play well together!
+
+Zarro has you covered here. The heart of Zarro was originally built for gulp 3.
+Version 4 came out and broke _everything_. I didn't feel like rewriting perfectly
+acceptable tasks, but I did want to keep up with the latest version of `gulp` and
+the speed advantages that were promised. As such, Zarro can consume and adapt
+gulp 3 tasks to run under gulp 4.
+
+## Getting started
+
+1. `npm init -y` (if you don't already have a `package.json`
+2. `npm install --save-dev zarro`
+3. start adding scripts! for example:
+    ```json
+   "scripts": {
+       "build": "zarro build",
+       "test": "zarro test-dotnet",
+       "zarro": "zarro"
+   }
+    ```
+(the `test-dotnet` task should invoke zarro's inbuilt `build` task (and some earlier
+ones to download tooling, as required) so that when test-time comes, assemblies
+are already built (required for .NET Framework / NUnit runner, and optimised for
+`dotnet` by performing the build and testing without rebuild)).
+
+## What's in the box
+There are an array of pre-defined tasks you get out of the box with zarro. I hope to eventually
+provide more documentation for them, but running `zarro --tasks` should tell you something
+similar to:
+
+- help
+  - shows help / usage
+- help:environment
+  - shows help about environment variables zarro observes (same as running with --help)
+- build
+  - attempts to build all found .net solutions
+- test-dotnet
+  - test .net projects based on conventions
+    - test project names should match `*.Tests` or `*.Test` or plain old `Tests`
+    - assumes test are nunit
+- cover-dotnet
+  - test with coverage
+  - can use dotCover or OpenCover
+- generate-reports
+  - generate html reports from OpenCover results
+- default-tools-installer
+  - installs the default helper tooling from nuget
+    - nunit cli
+    - dotCover
+    - OpenCover
+    - ReportGenerator
+- install-tools
+  - called before build
+  - defaults to install default tools
+  - override with an empty task if not useful
+- dotnet-publish
+  - runs dotnet cli build with publish options
+- nuget-restor
+  - restores nuget packages
+  - run automatically as part of build
+- release-npm
+  - perform guided release of npm packages
+  - can do beta releases
+  - will automatically
+    - increment version
+    - git commit
+    - git tag
+    - git push
+- update-self
+  - updates to zarro@latest
+- update-git-submodules
+  - updates all git submodules in the repo
+- pretest
+  - place-holder: override this to run something before testing
+- verify-up-to-date
+  - verifies that the current branch is up-to-date with the main one
+    - will check against {remote}/{main branch} if possible
+
+
+Running the above would also list any custom tasks you have defined
+
+## Zarro doesn't do what I want out of the box
+
+Zarro is designed to be zero- to low- conf. You can guide many aspects of available
+tasks with environment variables. Running `npm run zarro -- --show-env` will show you
+all observed environment variables and where they are applicable. I suggest using
+`cross-env` and applying these variables in one place, to keep things simpler. For
+example, [NExpect](https://github.com/fluffynuts/NExpect) does the following:
+
+```json
+"scripts": {
+    "zarro": "cross-env DOTNET_CORE=1 BUILD_EXCLUDE=src/PeanutButter/**/* PACK_INCLUDE=* PACK_EXCLUDE=*Tests*,CoreConsumer,src/PeanutButter/**/* TEST_EXCLUDE=src/PeanutButter/**/* zarro",
+    "build": "run-s \"zarro build\"",
+    "test": "run-s \"zarro test-dotnet\""
+}
+```
+
+in the above:
+- `DOTNET_CORE=1` instructs zarro to use `dotnet` instead of searching for `msbuild`
+- `BUILD_EXCLUDE=...` instructs zarro to exclude everything under that folder, recursively
+  (NExpect imports PeanutButter as a submodule to use some shared code without relying
+   on another package dependency)
+- similarly `TEST_EXCLUDE` excludes PeanutButter tests
+- similarly, `PACK_INCLUDE` and `PACK_EXCLUDE` control nuget packing within NExpect
+
+## Custom tasks
+
+Zarro will also search two folders:
+- local-tasks
+- override-tasks
+in the root of your repo, for extra tasks that you can access from your npm scripts.
+
+These can be brand-new functionality you'd like to add to your repo's build system,
+or you can _override existing tasks_, if they don't suit you. For example, if the `pack`
+task doesn't do exactly what you want, copy `pack.js` from `node_modules/zarro/gulp-tasks`
+into your `local-tasks` folder and modify it to suit you. If you find a generic solution
+to the problem you have which others might find useful or fix a bug, I'd like to know
+about it. PRs for fixes and extension tasks which others could use will be appreciated.
+
+## Examples of custom tasks that I've written in the past
+- a watcher to automatically recompile scss to .css
+- orchestration of build / test of sub-projects that aren't .NET
+- automatic version incrementing of packages before release
+- committing, tagging and pushing new changes to GitHub
+  - I've found that writing a meta task called `release` can make it much
+    less painful to perform a release of my nuget packages, for example.
+    This meta task would:
+      - build
+      - test
+      - increment package versions
+      - pack
+      - push packages
+      - commit the updates package definitions
+      - tag the release
+      - push the tag and changes to GitHub
+
+## API
+
+Zarro provides some convenience functionality from baked-in modules. To access a module,
+the global `requireModule` function will resolve the correct location for you. Modules
+live under the `gulp-tasks/modules` folder. Most modules will return a single function,
+though there are some exceptions. Some modules may be of interest to custom tasks, eg:
+
+- `gulp`
+    - you should `requireModule("gulp")` wherever you would have normally
+        done `require("gulp")`. This gets you the patched version of gulp 4 which
+        will happily consume gulp 3 tasks and which has inbuilt support for help
+        for your tasks on both gulp 3 and 4. Most importantly, if you _do not_ use this
+        export, your tasks may not be correctly registered.
+- `env`
+    - provides a utility object to resolve environment variables for you
+        - `register` can register an environment variable as known with a default
+           value and help. See `register-environment-variables.js` for examples.
+           When you use this function, you can have a central configuration for
+           a default value for an environment variable and your environment
+           variable will be displayed in the `--show-env` output
+        - `resolve` resolves environment variables for you. It can be invoked with
+            one or more variable names, so can be used to fall back from one variable
+            onto another. It will also resolve back values if registered.
+        - `associate` associates one or more variables with one or more tasks,
+           primarily to show which tasks are affected by which variables when
+           running with `--show-env`
+        - `resolveArray` can resolve an environment variable to an array for you,
+            with an optional `delimiter` parameter, which defaults to comma
+        - `resolveNumber` resolves a numeric value from the named environment
+            value or throws if the value can't be resolved as a number, effectively
+            stopping execution. If you're expecting a number (eg port or max thread
+            count) you can simply `resolveNumber` and an invalid value would cause
+            execution to stop with a reasonable message
+        - `resolveFlag` resolves boolean values from environment variables
+            - `true` for: "yes", "true" or "1"
+            - `false` for: "no", "false" or "0"
+            - throws for unknown values
+- `resolve-masks`
+    - single function to resolve an array of masks that could be used in a `gulp.src`
+        where those masks can be inclusive or exclusive
+- `find-local-nuget`
+    - provides a single function to find a locally-downloaded `nuget.exe`, automatically
+        downloading it if required. Use this if you need to use `nuget.exe` operations
+        and don't want to set up your build host with a pathed `nuget.exe`
+- git utilities
+    - `git-tag`
+    - `git-push`
+    - `git-push-tags`
+- string padding
+    - `pad`
+    - `pad-left`
+    - `pad-right`
+
+There are many more utilities in there, feel free to browse the source.
+
+## History
+
+If you've made it thus far, some light history might be of interest. Zarro's core
+functionality comes from another repo of mine: [gulp-tasks](https://github.com/fluffynuts/gulp-tasks)
+which was traditionally consumed as a git submodule. However, it seems that a lot
+of people don't really "get" git submodules:
+- people forget (or don't understand that they need to) `git submodule update --init` after
+  a `git clone` or a `git pull`. Some modern git clients are doing this for the user,
+  but not all of them.
+- people don't seem to understand how submodules are stored (literally just a hash and
+  an url), so they don't pay attention when committing them. In particular, I have seen
+  my fair share of inadvertent "submodule wars" where changes upstream aren't applied
+  after a `pull` (ie, people forget to run `git submodule update --init`), then they
+  re-commit back the _old version_ of the module that they have locally. So fixes tend
+  to become unfixed
+- in addition, `gulp-tasks` requires dependencies to be installed in the hosting repo's
+  package.json, meaning that (a) the hosting repo has to "know too much" about the
+  requirements of `gulp-tasks` and (b) upstream changes may require changes to a repo's
+  package.json (and an `npm install`). Whilst this was (eventually) automated as part
+  of `gulp-tasks`, it seems unnecessarily complex.
+- the solution seemed clear: make `gulp-tasks` available via an npm package
+- the name is inspired from the old bugzilla, which would proudly proclaim "zarro boogs"
+  when there were zero bug matches for a query, because (a) names are hard and (b)
+  zarro aims to be zero- to low-conf

package/gulp-tasks/.editorconfig

@@ -0,0 +1,8 @@
+root = true
+
+[*]
+end_of_line = lf
+insert_final_newline = true
+indent_style = space
+indent_size = 2
+trim_trailing_whitespace = true

package/gulp-tasks/.git

@@ -0,0 +1 @@
+gitdir: ../.git/modules/gulp-tasks

package/gulp-tasks/.gitignore

@@ -0,0 +1,9 @@
+node_modules
+*.swp
+*.swo
+*.un~
+npm-debug.log*
+modules/nuget.exe
+modules/nuget.exe.completed
+modules/nuget.exe.part
+.idea

package/gulp-tasks/LICENSE

@@ -0,0 +1,24 @@
+Copyright (c) 2015, Davyd McColl
+All rights reserved.
+
+Redistribution and use in source and binary forms, with or without
+modification, are permitted provided that the following conditions are met:
+
+* Redistributions of source code must retain the above copyright notice, this
+  list of conditions and the following disclaimer.
+
+* Redistributions in binary form must reproduce the above copyright notice,
+  this list of conditions and the following disclaimer in the documentation
+  and/or other materials provided with the distribution.
+
+THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
+AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE
+FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
+SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
+CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
+OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+

package/gulp-tasks/README.md

@@ -0,0 +1,144 @@
+# gulp-tasks
+### A gulp starter-pack
+---
+
+
+
+Some gulp tasks and utilities for building and testing .net and Javascript projects, favouring convention over configuration.
+     * Disclaimer: yes, I realise that this is a very opinionated take on the problem. *
+           * Feel free to submit requests (or better yet, pull requests) *
+
+
+## How to use this?
+
+This is a starting-point which you can use (and track) to get gulp building your project fairly painlessly.
+Here's what you do:
+
+1. add this repo as a submodule of your repo, at the root level
+2. copy `start/gulpfile.js` to the root of your repo
+3. run `node gulpfile.js` in the root of your repo. This should guide you through:
+    - initializing a `package.json` with your repo's details
+    - installing the node modules required by `gulp-tasks` to run
+    - setting up two npm scripts:
+      - `gulp` which can be used to run gulp commands without a globally-installed gulp. Simply do something like `npm run gulp {taskname}`
+      - `test` which will run the `test-dotnet` task from `gulp-tasks`
+4. if you know some gulp, you may augment tasks by creating new tasks in the `local-tasks` folder parallel to the `gulp-tasks` folder
+5. override provided tasks by copying them to the `local-tasks` folder
+    - edit them to your heart's content: you only have to edit the ones you want to change.
+6. First time: run `npm install` to install required modules
+7. Either:
+    - run `node node_modules/gulp/bin/gulp.js` OR
+    - install gulp globally with `npm install -g gulp` and then run `gulp`
+
+## Assumptions
+1. You're using MSBuild to build your stuff and Visual Studio for development (at least somewhere, so you get .sln files)
+- You're using NUnit for testing
+- You're using (or capable of installing) dotCover CLI (not required, but used by default)
+
+
+## What's in the box?
+
+Available tasks (at time of writing) include:
+
+- default
+    - this is the default task invoked if you just run gulp from the commandline. It should just contain a sequence of tasks to run for the default build
+    - the default will attempt:
+        * purge: remove all binary artifacts in bin and obj folders
+        * git-submodules: pull latest for any submodules
+        * install nuget packages for all solutions in the repo
+        * install tooling required by shell `install-tools` task
+        * build: msbuild your solution(s): all .sln files in the repo
+        * cover-dotnet: run all NUnit tests through dotCover (searches for dotCover and NUnit in
+            expected locations)
+        * run shell `generate-reports` task to output pretty reports.
+- build
+    - builds all Visual Studio solutions\*
+- clean
+    - invokes the 'Clean' target in all Visual Studio solutions\*
+- test-javascript
+    - runs karma in a single-run mode, recording coverage\*\*
+- git-submodules
+    - attempts to update all git submodules with the latest (HEAD) from the repositories they
+        point at. Think along the lines of svn:externals
+- nuget-restore
+    - attempts to restore all nuget packages for all solutions\*. Will download it's own
+    `nuget.exe` unless you specify otherwise.
+- test-dotnet
+    - (currently) attempts to run nunit tests from all Test projects, using a
+        convention-over-configuration method: All assemblies that it can find which end in
+        .Tests.dll are candidates for testing -- the ones selected must reside in the Debug build
+        output of a corresponding project folder, ie
+        `SomeProject.Tests/bin/Debug/SomeProject.Tests.dll`. The task will also look one up from
+        this if the Debug folder isn't found, so you can use this against test projects which are
+        Web projects at heart. \*\*\*
+- cover-dotnet
+    - attempts to run tests with coverage on your test assemblies. You will most likely want to
+      edit this task to add exclusions for external libraries and such that your test project is
+      using, though the defaults are sane. Will attempt to find installed or local dotCover
+      or OpenCover to run coverage with
+- install-tools (now a default part of the pipeline - see the `install-tools.js` file for information on how to disable this task, if it's not interesting to you)
+    - install local build tools to the tools/ folder in your solution (by default, can be overridden by the BUILD_TOOLS_FOLDER environment variable)
+    - depends on `default-tools-installer`, providing:
+        - nunit.console
+        - opencover
+        - reportgenerator
+- shell tasks (have no default behavior, but hook into the build pipeline):
+    - generate-reports
+        - generate reports after building
+        - you can get sane behavior by creating a local task which depends on
+            `default-report-generator` which uses reportgenerator to give
+            html coverage reports.
+
+
+\* That can be found in the current folder or any descendant folders
+\*\* Looking for (presently) a karma.conf.js in the same folder as the gulpfile. There are plans to make this task also seek out karma.conf.js files in descendant folders but the actual need hasn't arisen yet.
+\*\*\* These tasks attempt to find the highest stable releases of their dependancies (dotcover.exe and nunit-console-{platform}.exe) according to default install paths by default.
+
+## Shell tasks
+Shell tasks do nothing out of the box. You have to opt into the default behavior or write your
+own. If you think that the default behavior is what you want, create a task which simply depends
+on the default behavior. For example, if you want local tooling and reports out of the box, you
+could create `local-tasks/use-default-tasks.js` with:
+```
+const gulp = requireModule("gulp");
+gulp.task("generate-reports", "Generate coverage reports", ["default-report-generator"]);
+```
+
+The default behaviors here are left out so as not to interfere with existing users. `install-tools` has been included by default now that I find I need it more often than not. Anyone who updates their reference to `gulp-tasks` and sees extra stuff being done should follow the instructions in `install-tools.js`.
+
+## Using modules from `gulp-tasks`
+If you want to use any of the modules found under `gulp-tasks/modules`, make use of the
+globally-available `requireModule` function. Some available modules include:
+- `gulp`
+    - uses `gulp-help` (for v3 gulp) to provide a modified `gulp` where a second parameter can
+        be provided to give useful help. Read more on the `gulp-help` documentation.
+- `http-downloader`
+    - provides a simple async http downloading class
+- `spawn`, `exec`
+    - provides fairly safe ways to start processes on Windows
+- others can be seen in use in provided tasks
+
+## Convention over configuration
+
+These tasks were designed to cater, unedited, for the majority of build requirements\*, for example:
+- One main .sln file (if you have multiple, *all* are built -- override in your own build.js)
+- Test assemblies are named {Project}.Tests.dll (this is important: the test assembly collector will be quite stoic about it)
+- karma.conf.js lives alongside your gulpfile (if running JavaScript tests)
+- msbuild is set to build in x86 output using tools version 4.0 for Mono compatibility
+
+However, these (and other) assumptions may not fit your needs. The ethos of the project is that, in
+providing smaller task files, you can select only the ones you want and make changes to them if you
+need to to suit your needs. If you really want to merge in upstream changes, it should be an easy
+task because of the separation. It should also be easy to extend with your own tasks -- just add them
+to the gulp-tasks folder and reference them in your default pipeline to have them run by default.
+
+
+## Kudos
+
+All of this is only possible because of Node, Gulp and all of the contributions for tasks and modules,
+not to mention NUnit and dotCover (both free and excellent).
+Before attempting to write your own pipelining module for Gulp, look online -- someone has quite
+likely already done it. But if you *must*, then I highly recommend having a look at the
+gulp-nunit-runner module: it was the basis that I ripped off for the gulp-dotnetcover module (which I
+probably should try to get into official npm sources at some point, but for now, it lives
+under gulp-tasks/modules)