hercules command

[domenkozar]

trafficstars

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 [email protected] 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 https://github.com/hercules-ci/hercules/issues/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?