Github user NightOwl888 commented on the issue:
https://github.com/apache/lucenenet/pull/191
@conniey - Thanks for the info.
I have setup several projects in both TeamCity and on MyGet before, so I am
familiar with the process. Basically, TeamCity both has built in tools that can
run different plugged in processes AND it can also run external scripts. It is
just a matter of adding the build steps in TeamCity to run the internal or
external processes, which I am confident Wyatt or someone on his team is
familiar with.
The only thing we need to deliver is a script that can be used to run each
of the tasks (build/test/pack, etc), and the corresponding CLI command or
commands to run them (and of course the links to any dependencies required on
the server).
> Is there an existing build script/steps I can look at?
Sure, here are some examples
https://github.com/maartenba/MvcSiteMapProvider/tree/master/build - This
one has multi-targeting, and uses PowerShell/PSake for the build tasks. It may
be a bit too complex for what we need, but it can be scaled down.
https://github.com/NightOwl888/BoboBrowse.Net/tree/master/build - Here I
took the same script and scaled it back for a project with fewer requirements.
https://github.com/snikch/jquery.dirtyforms/blob/master/gulpfile.js - Here
is an example in Gulp rather than PowerShell. Again, more complex than we need
because it is used to update many Git subprojects, but can be scaled down
easily. Here is its corresponding JSON file:
https://github.com/snikch/jquery.dirtyforms/blob/master/package.json
PowerShell/PSake
-----
| Pros | Cons |
|---|---|
| Language you and I are both familiar with | Requires extra PSake (or
similar) script to manage tasks |
| Can run .NET functionality natively | Tasks run synchronously by default
|
| If we end up making a NuGet install.ps1 script, it will be the same
language as the build script | Generally more code to maintain |
Gulp
-----
| Pros | Cons |
|---|---|
| JavaScript, so familiar syntax to lots of people | Requires plugins to
work, and they may vary in quality |
| Doesn't require an extra script to manage the tasks | Plugins are
updated frequently - need to be sure that you specify the exact versions for
plugins or the script may break (by default they upgrade automatically) |
| Script runs asynchronous by default, so long running tasks can run
parallel | Asynchronous by default sometimes makes it difficult to inline
functionality |
| Tasks can be managed from a JSON file | |
Gulp has a nice CLI syntax that is straightforward
```
gulp <taskname>
```
or to run the default task configured in package.json
```
gulp
```
Build Option
-------------
IMO, the best option appears to be option 1. The fewer build tools it takes
to get the job done is definitely going to be the simplest route. Not to
mention, I would like to get my feet wet (or wetter?) with the newer tooling -
it has been about a year since I last dealt with it.
From the build script standpoint, it doesn't really matter too much as long
as the build server can do it. The script itself can be broken into multiple
tasks, each which has a separate CLI command to run and then tied together with
a master script and/or the task steps in TeamCity.
Perhaps Itamar can setup something like TravisCI, which can be configured
on GitHub to run the unit tests when someone submits a PR..? Then we wouldn't
have to worry so much if contributors have the right tooling to run the tests.
If you ask me, having TeamCity in the mix is a bit overkill for this
process - MyGet is plenty capable of doing everything we need to build, deploy,
and version the builds. But if you set it up so it works on MyGet (which
interestingly doesn't require a command to push the NuGet packages to the
feed), then it should be possible to use the same script on TeamCity.
Here's an idea - why not make the script smart enough (at least for running
tests) to detect if the right tools are installed and error out giving the
appropriate info on what tool is required (and perhaps the URL where to get
it). Also, perhaps it could list a command or commands that are possible with
the current tooling to run the tests on one framework or another. Just thinking
out loud...
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---
