hercules command

[domenkozar]

Once we have the RESTful API, I'd like to have a CLI client that's first class citizen user of it + Nix underground.

API Sketch:

# Parse yaml, build the project using plain nix-build locally (useful for testing)
$ hercules build

# Parse yaml, print what is about to be built (dry-run)
$ hercules build --preview

# Between the last failing build and last suceeding build, find the commit that broke the build
$ hercules bisect

[expipiplus1]

This is a good idea. It makes me think that we should consider splitting out the build worker from the program which exposes it as a rest api. Or, this cli program could just use the rest api at localhost, spinning up a server if necessary.

…

On Tue, Jan 3, 2017, 12:27 PM Domen Kožar ***@***.***> wrote: Once we have the restful API, I'd like to have a CLI client that's first class citizen user of it. API Sketch: # Parse yaml, build the project using plain nix-build $ hercules build # Parse yaml, print what's about to be built $ hercules build --preview — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#12>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA0U3Bsyl5ZbPZu7n0o6yK1BYoxnuADXks5rOj6hgaJpZM4LZkyK> .

[ghost]

For local installation or for use against a central server instance? If it is for a local installation, consider having the local version use a simpler db like acid-state or sqlite.

[lukego]

This would be awesome. I would love to be able to have one pool of servers for both CI use and also direct interactive use. This seems a bit tricky with the current nix ecosystem. I don't see how to make Hydra and distributed nix-build jobs coexist in a smooth way. Seems like a neat solution would be for nix-build to issue the request to Hydra rather than talking with all the build slaves directly, and perhaps that is what hercules build would do?