lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From NightOwl888 <>
Subject [GitHub] lucenenet issue #191: Migrating Lucene.Net to .NET Core
Date Tue, 15 Nov 2016 21:43:28 GMT
Github user NightOwl888 commented on the issue:
    @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 - 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. - Here I took the same
script and scaled it back for a project with fewer requirements. - 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:
    | 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  | 
    | 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
    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 or file a JIRA ticket
with INFRA.

View raw message