It should be possible to have Hercules limit access to projects, jobset, jobs, logs and outputs to only those users that have been explicitly granted access to them. This is particularly important for companies who are developing their own proprietary software and only want their staff to be able to access the Hercules UI and do things there. It should also be possible to distinguish between read-only and read-write levels of access.

Currently we install node+elm packages in nix-shell, it would be nice to Nixify that.

Either manually or using NixOS/nixpkgs#20601

To get first version:

1. Generated list of elm packages in nix
2. Call mkFrontend with the list
3. Which in turn calls makeElmStuff
4. and that generated the folder

This will still probably use networking to check if newer packages exist.

Using

putStrLn . fromMaybe "Empty query" . showSqlForPostgres

I'd essentially like to turn https://github.com/mayflower/hydra-jobs/blob/master/spec.json into something more .travis.yml alike.

inputs:
  nixpkgs:
    type: git
    value: git://github.com/mayflower/nixpkgs.git

notifications:
  email:
    - [email protected]

Input types:

• git
• mercurial
• boolean
• nix
• string
• previous build
• previous evaluation

Linting:

• error out if section appears two times

I'd like to have a meta issue to see how far we are from using this in the real world.

• authentication
  • Backend: support Github authentication
  • Backend: store information into the DB
  • Frontend: wire up the buttons
• github hooks to trigger evaluations
  • sharing the secret
• jobset page
• job page
• user permissions upon registering?
• declarative configuration
• add project (a simple way to setup web hooks and declarative configuration)
• hydra-evaluator integration
• hydra-queue-runner integration
• hydra-eval-jobs integration
• serve narinfo
• serve nar
• Hydra migration? How to migrate to declarative configuration?
• Documentation
  • FAQ
  • API
  • Getting started
  • Design decisions
• NixOS module

maybe we can add a list of things to do, so that people unfamiliar with the project (like me) can have a simple objective to start with.

maybe a tag on issues.

In pkgs.nix you can use the deterministic bootstrapping style described in NixOS/nix#1299 (comment) to prevent the user from having to redownload the tarball hourly.

In this very early stages of development, we expect an existing Hydra DB.

For Hercules to really work for users, we need to use Hydra source and run it's sql creation script.

Further on, we'll have to compile C++ executables (hydra-queue-runner, hydra-evaluator, hydra-eval-jobs, ..) for handling the queue.

Not entirely sure how this would work. Here's the use case

We have two set of builds, one which builds our haskell packages, and the other which builds an identical set of packages but with profiling. It would be very handy to only build the profiling version of a package if the non-profiled version worked.

I suppose that this could be done already by inserting a dependency in the nix expression, but that's really gross.

Provide a way to generate an image if build is failing or not. Try using https://shields.io

travis-ci has the same feature

• Design the badge
• API endpoint for an image
• Markdown generator
• Display number of builds passing out of total

I could not determine the license this code is under, could this be resolved?

This is something hydra is currently lacking which would be a nice-to-have in hercules.
Build status should be retrievable across jobs in a jobset via a badge.
http://shields.io/

We need to be able to evaluate and realise nix expressions while also knowing what was required for this build.

I've have an implementation of a dummy nix-store api https://github.com/expipiplus1/dummy-store which allows us to intercept any store commands. This can be used to watch for build commands and take appropriate action.

https://linux.die.net/man/1/ts

Would be nice to support this feature. This allows the artifacts of successful builds to be downloaded directly.

As far as I've been able to tell, Hydra does the following to figure out what to build:

1. Evaluate your jobsets
2. Pick a job, anywhere
3. Build it
4. Farm out its subtasks across remote builders

This leads to sometimes me starting a branch in it and seeing haskellPackages.foo being the first job being built. If I check the Steps tab for that job, I see that it's downloading the bootstrap tools, bootstrapping the stdenv, and so on. Given that the bootstrap steps aren't explicitly named jobs, it can be hard to track them down.

More intuitive to me would be:

1. Evaluate jobsets
2. Understand the dependency graph
3. [Optional] Let me explore it somehow
4. Start evaluating based on the graph
5. [Optional] Prioritize builds based on how many downstream builds they enable

Or some variation of that.

See krisajenkins/elm-export#20

Currently s/'//g fixes this.

http://hydra.earthtools.ca/eval/7093#tabs-inputs

with some jobsets, the result of the eval is rarely changing(only things impacting 1 package), even when a large number of commits are happening

and with the old hydra logic, it will show all commits between the last eval and the current eval, including stuff that had no effect on the eval

but hercules could record the commit of every eval that had no differences detected, and could then cut the commit range down to just the poll interval

Having a NixOS package/module would make it easier to try out hercules. I saw that this is already mentioned in #5 , but I think this warrants it's own issue.

I noticed that some dependencies (opaleye-gen) are not on hackage yet, I assume this is a blocker for this?

As a side effect of running Hydra one gets a binary cache that can be served through SSH using the SSH substituter mechanism from Nix. This way of accessing the cache through SSH access is very useful for those only willing to share the build outputs with those who have explicitely been granted access (see #22). It would be nice if allowed SSH keys for these users could be managed from the Hercules UI.

http://hydra.nixos.org/job/nix/master/coverage#tabs-charts

data is stored in $out/nix-support/hydra-metrics and as an example content

lineCoverage 68.2 %
functionCoverage 67.2 %

hydra will log the values at every build, and graph how they change over time

This may be a little premature, but I thought it might be useful to think about how Hercules could be provided as a service. Basically, I'm thinking of a competitor to Travis CI. While it's hard to complain too much about Travis CI when they are providing a free service, it's definitely got enough drawbacks that an alternative would be useful.

Most of this is an organizational issue. Some org (maybe NixOS foundation?) that could provide servers to build Nix stores on demand. Free might be too hard to manage but a kind of fixed rate scheme could be fairly straightforward pricing based on CPU time, with any profits being reasonable. I believe Travis started out as a crowdfunding campaign, so maybe something like that is in order?

My basic thinking is to mimic Travis's design of signing up with your GitHub account and getting a list of your repos with `switches' to turn CI on or off. Instead of a .travis.yml file, however, we would just ask for a default.nix file to make things simple and by default build the derivation or set of derivations. Lots of Nix repos have this scheme, now. People not using Nix could even just use runCommand and some scripts if they didn't want to deal with Nix (although it would be much more ineffecient).

In addition, I don't know if anyone has thought about building PRs like Travis does. It shouldn't be too hard to just attach a GitHub event and track the PR branch like any other branch. Travis does some weird stuff with merging commits that in my opinion are bad design (why should a failing master branch mean my PR breaks?).

What do people think of a Hercules as a Service? (HAAS for short)

I propose we use Rst/Sphinx and thus https://readthedocs.org/ for hosting docs.

• export the Servant API to RST by implementing servant-httpdomain package using https://pythonhosted.org/sphinxcontrib-httpdomain/#basic-usage

• serve servant-swagger on /

cc @expipiplus1

Inspired by lukego/blog#17, it would be really interesting to explore bisecting in the CI:

1. Specify what range of commits to explore
2. Tell the CI which build indicates the success or a failure
3. Profit

Create a test suite for the elm portion and I will incrementally add unit tests. I can give you an example starter for creating a test suite if you need one.

It's no fun to play guessing games with Hydra about what it's spending its time on.

https://github.com/elm-lang/navigation/issues/13#issuecomment-272909513

For example:

instance ElmType Project where

Or check if upstream provides a way to add extra instances for each type.

Use upstream haskell-servant/servant-elm#20 to mitigate that.

cc @expipiplus1

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

It would be super to be able to estimate job build time. This might enable us to do some clever load balancing.

http://www.cs.uccs.edu/~xzhou/teaching/CS551/Projects/HeavyTailedTaskAssignment_JACM02.pdf