►
Description
In this lecture, Thomas (a.k.a. tomberek) will talk to us about Hydra, Nix's CI. You can expect an introduction to the Nix based CI project, Hydra. We will cover overall architecture, initial usage, limitations, benefits, and walk people through creating and managing their own projects.
Special thanks to the NLnet Foundation, the European Commission, the NixOS Foundation, and Tweag for making this event a reality!
The continued discussion for the lecture series is happening over here:
https://matrix.to/#/#son2022-lectures:matrix.org
More information about the Summer of Nix can be found on the website:
https://summer.nixos.org
A
I
hope
you're
all
ready
for
yet
another
installment,
the
nexus
2020.
Sorry
not
nexus
summer
of
next
2022
public
lecture
series,
I'm
never
going
to
get
used
to
pronouncing
that
fully
but
yeah,
I
hope
you're
ready
for
another
one,
but
before
we
get
started
of
course,
the
usual
I'd
like
to
thank
the
people
that
make
it
possible,
and
they
also
like
to
accentuate
this
time,
that
the
people
that
also
made
this
possible
is
the
participants.
A
So
thank
you
for
participating
in
the
summer
of
next
2022
as
well,
and
I've
heard
and
seen
that
you
guys
are
doing
some
pretty
great
work.
So,
thanks
to
this,
that's
it
to
the
now
to
the
nlnet
foundation,
to
the
european
commission,
the
nexus
foundation
and
the
tweak
for
their
support
and
yeah.
Without
holding
you
guys
up
any
longer.
I
will
pull
tommen
here
who's
going
to
talk
about
hydra,
so
yeah
welcome
tom.
B
Hello,
everyone,
I
guess
so
my
name's
tom
berechni
I've
been
in
the
mix
community,
for
I
think
approaching
a
decade
now
and
I'm
a
big
fan
of
essentially
how
this
technology
is
used.
How
it
can
just
and
an
aspect
of
this
is
something
called
hydra,
so
today
we
are
going
to
be
bringing
up
basically
an
introduction
to
hydra.
B
B
So,
let's
get
started.
Hopefully
everyone
can
see
this
all
right.
So
again,
this
is
gonna,
be
a
little
bit
about
you
know
what
hydra
is
why
it
exists
a
little
bit
about
how
to
get
started.
Then
we'll
talk
about
how
to
use
it.
This
kind
of
it
was
going
to
be
a
little
bit
opinionated,
but
this
is
just
an
example
of
how
you
can
use
it
for
your
own
projects
and
for
your
own
organizations.
B
Then
we'll
go
a
little
bit
into
like
what
it
takes
to
either
host
your
own
hydra.
Sometimes
there's
some
quirks
related
to
that.
If
that's
something
that
you
wish
to
do,
we'll
talk
a
little
about
how
you
want
to
like
edit
or
you
know,
change
hydra,
how
to
work
with
it
in
terms
of
distributing
to
it
or
modifying
it,
and
then
at
the
end,
we'll
go
hands-on
and
we'll
actually
run
through
some
examples
and
feel
free
to
add
in
any
questions
as
we
go.
B
If
there's
notice
something
I
might
just
kind
of
answer
in
line
or
we
could
kind
of
leave
some
things
toward
the
ends
depending
on
how
people
would
like
to
do
that
all
right.
So
what
is
hydra
hydra
is
a
you
know:
continuous
build
system
that
is
designed
to
work
natively
with
the
way
nics
operates.
So
it's
built
on
top
of
the
nyx
build
system,
the
nyx
package
manager,
and
it
does
this
continuous,
build
process.
B
The
jobs
that
it's
going
to
perform
are
all
declared
using
necks,
and
so
it
is
a
very
much
like
you
know.
You
eat
your
own
dog
food
sort
of
a
situation
and
trying
to
make
it
so
that
it
is
a
very
cohesive
thing.
The
idea
here
is
this
also
kind
of
supports.
Like
the
you
know,
automatic
builds
automatic
updates
as
things
get
pushed
along
in
terms
of
source
code
or
in
terms
of
repositories.
B
All
of
this
is
managed
for
you,
and
you
know
somewhat
of
a
nice
way
and
provides
a
user
interface
and
provides
a
larger
build
system
for
you
to
like
run
through
this
original
paper.
Guy
was
is
interesting
to
read
through
this
is
kind
of
where
hydra
came
from.
So
I'll
include
a
these
slides
in
a
link
at
the
conclusion,
but
you
kind
of
go
through
an
initial
discussion
of
where
the
hydra
goes.
It
comes
from
some
of
ilco's
work.
B
You
know
way
back
when
and
currently
there's
a
hydra
instance
that
kind
of
manages
and
does
the
like
largest.
I
guess
deployment
of
this
is
to
do
the
builds
for
nyx
packages.
One
of
the
main
purposes
of
the
hydra
that
we
have
deployed
at
the
moment
is
to
build
everything
in
mixed
packages
and
to
populate
a
cache.
The
big
benefit
of
this
is
that
now
nick's
users
don't
have
to
build
everything
from
source
themselves
or
to
have
their
own
cache,
but
now
they
have
the
benefit
of
binary.
B
Caching,
for
essentially
almost
everything
that
exists
index
packages,
there's
exceptions
with
regards
to
things
that
either
don't
build
or
things
that
are
unfree
and
there's
no
various
policy
reasons
for
those.
But
for
the
most
part,
this
is
what
powers
enzo
is
huge
benefit
for
the
knicks
community,
and
so
keeping
that
system
healthy
and
alive
is
one
of
the
responsibilities
of
the
community.
B
I
kind
of
grabbed
this
from
a
slide
from
sander
vanderburgh,
basically
describing
a
little
bit
more
about
you
know
what
hydra
itself
is.
So
this
is
a
build
system,
but
it's
also
generic.
So
it's
kind
of,
in
that
case
a
meta
build
system,
and
in
that
sense
it
can
do
builds
for
various
different
languages.
This
is
inherited
because
of
how
it
uses
nics
as
its
builder.
B
This
can
also
support
deployment,
so
we
can
also
use
hydra
to
either
like
push
things
to
other
places,
or
it
can
also
be
served
as
a
thing
to
pull
things
from.
So
you
get
idea
of
things
like
the
latest
build.
You
have
concepts
like
running
hooks
at
the
end
of
a
of
a
build,
you
can
populate
a
cache,
push
things
into
a
cache
at
the
conclusion
of
builds.
All
these
concepts
help
you
know
utilize
hydra
as
a
deployment
tool.
B
You
can
kind
of
have
many
different
kinds
of
builds
that
all
coexist
right.
This
isolation
that
we
get
again
from
the
you
know
underlying
nix
basis
of
it
gives
us
isolation.
We
can
kind
of
support
multiple
architectures,
you
can
support.
You
know
variations
of
builds
and
all
these
coexist.
They
don't
interfere
with
with
each
other.
B
This
means
you
don't
have
to
have
a
essentially
a
fresh
vm
or
a
fresh
container
building
everything
and
you
get
a
lot
of
reuse.
This
is
one
of
the
benefits
of
using
hydra
is
that
the
the
reuse
between
builds
is
very
high
because
you're
using
you
know,
essentially
the
same
machines,
you
reusing,
store,
pads,
you're
reusing
dependencies
in
a
in
a
pretty
beneficial
way.
B
So
next
we
have
a
you
know.
I
mentioned
a
little
bit
about
multi-platform
support.
So
if
you
have
different
kinds
of
builders,
different
machines,
you
can
kind
of
hook
all
these
up,
so
that
if
there's
some
sort
of
a
of
a
build
or
there's
some
sort
of
a
package
that
requires
either
unique
hardware
or
it
just
needs
to
be.
You
know
built
on
a
particular
kind
of
machine.
Then
that
is
all
supported,
and
these
builds
get
distributed
and
pushed
out
to
the
correct
builders.
B
All
the
logs
and
all
the
build
artifacts
are
also,
then
you
know
brought
back
into
a
central
location
and
are
then
available
this.
It
could
be
used
in
all
sorts
of
very
interesting
ways,
but,
generally
speaking,
that's
you
know
a
helpful
thing
scalability.
So
this
is
the
next
piece
which
is
you
know
when
you
get
to
something
to
the
size
of
mixed
packages,
you're
going
to
need
to
want
to
have
lots
of
machines.
B
You
can't
just
have
like
one
beefy
machine,
do
everything
and
so
to
spread
the
load
out
and
just
starts
doing
a
little
bit
of
dynamic
scaling.
Hydra
gives
the
capability
to
do
that.
So,
once
your
the
builds
you're
doing
are
expand
beyond
the
scope
of
a
single
machine,
we
try
to
do
a
little
bit
more
capability
here.
B
B
This
is
how
it
kind
of
does
all
the
builds.
The
sandboxing,
those
builds
the
you
know,
orchestration
of
them
a
lot
of
how
the
the
builds
are
distributed.
Kind
of
what
sorts
of
machines
are
available.
All
this
is
kind
of
core
nics
functionality,
that's
being
used
for
the
purpose
of
performing
these
larger
scale.
Continuous
builds.
B
B
B
All
this
information
is
what
goes
in
the
database
and
depends
on
postgres.
That
database
could
be
kind
of
posted
on
the
same
machine.
That's
hosting
your
hydra.
It
can
also
be
a
remote.
You
know,
instance
in
case
you
want
to
have
you
know
some
sort
of
failover
or
you
know,
distinguishing
between
whatever,
like
your
hydra
server
is
and
where
that
database
is
hosted,
but
yeah,
it's
just
a
postgres
instance.
B
Next
we
have
the
evaluator.
This
component
is:
what
takes
your
you
know,
your
expressions
that
define
your
jobs
and
evaluates
them
and
tries
to
basically
find
jobs
to
do
the
point
of
this
is
to
kind
of
collect
everything
and
to
then
set
this
up
and
organize
them.
For
example,
some
of
these
jobs
might
require
certain
kinds
of
hardware
or
certain
system
features
or
require.
You
know
certain
sorts
of
architectures.
B
So
that's
how
hydra
will
know
how
to
distribute
these
jobs
and
where
they
should
go.
You
know
the
scheduler
now
tries
to
also
make
sure
that
you
do
things
in
order
right.
If
you
have
a
job,
that's
going
to
be
required
for
other
jobs,
then
obviously
you
want
to
do
things
in
correct
order
and
distribute
that
accordingly
qrunner.
B
This
is
the
piece
that's
going
to
take
all
those
jobs
that
are,
you
know
in
the
queue
and
start
going
through
and
try
to
try
to
make
sure
that
those
jobs
are
again
distributed
and
then
once
they're
done,
everything
is
kind
of
pulled
back.
All
the
logic
that
you
might
need
to
run
like.
Let's
say
you
might
want
to
run
hooks
or
you
need
to
run
jobs
at
the
conclusion
of
those.
These
are
kind
of
the
responsibilities
of
the
the
q
runner
there's
a
server
involved.
B
This
is
to
give
you
your
your
apis
to
give
you
a
web
page
and
an
interface,
and
these
are,
you
know,
somewhat
independent,
and
they
you
know
they
interact.
You
know
to
get
basically
the
job
done
of
giving
us
a
you
know,
fully
functioning
hydrants
implementation,
wise,
there's
a
whole
bunch
of
you
know
pearl
running
under
the
hood.
This
is
just
based
on
the
historic
nature
of
where
this
came
from
and
made
it.
You
know
possible
to
get
this
up
and
running.
B
So
if
anyone
has
a
lot
of
pearl
experience
and
knowledge
and
wants
to
contribute,
contributions
are
always
welcome
all
right.
Why
do
we
have
hydra?
You
know,
question
would
be
hey.
Why
not
just
use
some
other
ci
paradigm?
Well,
what
happens?
Is
you
know
a
lot
of
most
other
ci
paradigms?
Are
these
days
kind
of
based
on
some
sort
of
containerization?
B
So
there's
a
there's,
a
large
degree
of
isolation
that
you
get
between
those
and
that's,
not
necessarily
the
friendliest
in
terms
of
how
nyx
operates.
Nyx
can
kind
of
work
in
other
container
systems,
but
it
doesn't
leverage
next
to
its
full
benefits.
So
a
good
example
of
this
is,
if
you
have
a
bunch
of
jobs
that
are,
let's
say
slight
variations
of
each
other
and
they
reuse
a
lot
of
dependencies
right.
Those
already
exist
in
the
file
system
when
you're
talking
about
a
hydra
builder.
B
It's
everything's
kind
of
all
present
already,
whereas,
if
you're
doing
every
single
build
in
some
sort
of
a
fresh
container,
you
have
to
kind
of
do
a
lot
of
work
to
kind
of
re-bind
mount
everything
in
the
right
way,
redoing
a
lot
of
the
sort
of
work
that
nixon
already
can
do,
and
it
can
do
it
in
a
very
efficient
manner.
It
can
fetch
things
and
reuse
a
lot
of
those
dependencies
that
sometimes
you
know,
other
ci
systems
or
like
docker-based
systems,
are
going
to
have
a
hard
time
doing.
B
B
B
You
don't
want
to
deal
with
distributing
it
yourself,
and
you
want
this
to
be
kind
of
a
little
bit
more
scalable
have
a
little
bit
more.
You
know,
fault
tolerance,
then
running
hydra
kind
of
gives
you
this
capability
to
say
hey.
I
have
a
lot
of
work
to
do.
I
just
want
to
run
continuously
and
I
don't
have
to
worry
about
it.
B
B
B
This
is
we'll,
say
the
the
main
hydra
run
by
you
know
the
the
knicks
community
and
the
nixos
foundation,
and
it
serves
as
like
the
kind
of
the
the
main
hydra
that
is
going
to
build
and
run
all
of
the
next
packages.
There's
you
know
several
projects
that
we're
supporting,
and
you
know,
service
builders
for
but
the
biggest
one
to
be
familiar
with.
Is
you
know
mixed
packages
and
building
of
that
there's
a
large
set
of
infrastructure
around
it.
There's
a
lot
of
machines
that
are
available.
B
You
can
go,
see,
hey,
there's
a
whole
bunch
of
them
they're
doing
various
sorts
of
builds
at
the
moment.
So
that's
various!
That's
that's
relatively
helpful.
There
is
also
a
hydra
that
was
used
for
summer
of
nix,
that's
available
for
the
participant
at
ngi.
So
let's
go
take
a
look
at
that.
Here's
another
one!
It's
another
deployments,
an
independent
deployment
from
the
from
the
other
one
for
a
little
bit
of
you,
know,
fault,
tolerance
and
also
to
try
out
different
features.
B
C
B
B
So
that's
how
you
can
get
started.
You
can
get
yourself
an
account
there
there's
various
ways
to
have.
You
know
those
logins
created,
but
that's
how
you
can
get
started
contact
administrator
yeah.
So
once
you
get
a
user
account,
you
can
get
additional.
You
know
permissions
either
to
create
projects
or
to
kind
of
manage
them
in
various
ways.
B
Sometimes
it's
helpful
to
have
permissions
in
the
the
big
hydra
to
like
restart
jobs
or
to
help
kind
of
cancel
things
that
you
know
are
going
to
fail,
so
it
doesn't
like
take
up
compute.
Some
of
that
management
goes
into
how
the
you
know.
Nyx
packages
releases
take
place
as
well,
so
maybe
we
can
kind
of
get
started
here,
so
the
basic
first
basic
things
you're
going
to
want
to
do
is
like
hey.
I
have
a
I
have
a
project
I
want
to
create
job
set.
B
B
So
you
know
you
can
enable
them,
make
them
visible
and
visible
kind
of
get
some
information
about
like
what
to
call
it
where
to
put
it.
You
can
start
putting
in
information
like
you
know
who
the
owner
is,
there's
some
capabilities
here
to
kind
of
email
people
if
a
build
or
a
project
that
they're
responsible
for
breaks.
You
know,
sometimes
that's
useful,
sometimes
not
so.
Turning
that
on
and
on
on
and
off
is
a
choice
that
you
have.
B
Lastly,
down
here,
there's
a
section
here
called
a
declarative,
spec
file
for
now
we're
going
to
leave
this
blank,
but
we'll
come
back
to
this
to
kind
of
describe
what
this
is.
But
basically,
if
you
want
to
not
go
through
the
work
of
just
defining
your
own
job
sets
or
if
you
want
your
job
sets
to
be
dynamically
declared.
B
So
a
really
good
example
of
this
is
that
you
might
want
a
job
set
created
for
every
single
pull
request
to
a
project
you
may
have,
if
so
right,
there's
a
mechanism
to
make
that
possible,
and
you
can
do
that
by
having
declarative
job
sets.
We
call
that
a
dynamic.
You
know
job
sets
we'll
skip
that
for
now
and
leave
that
blank,
and
we
will
create
a
project.
B
B
B
The
type
here
talks
about
how
you're
going
to
to
declare
your
projects
there's
flake
and
legacy
for
most
of
summer
and
nix,
we've
kind
of
adopted,
the
experimental
features
of
flakes,
and
so
for
now
I'll
demonstrate
this.
There's
equivalence
in
terms
of
legacy
and
in
fact,
hydro
support
for
legacy
is
actually
a
little
bit
better.
B
It's
kind
of
a
little
bit
more
tightly
integrated,
there's
capabilities
kind
of
in
the
pipeline
to
make
the
flick
integration
better,
but
it
also
is
more
convenient
to
get
started
so
from
getting
started
perspective
these
days.
I
do
recommend
that
hey,
if
you
already
have
a
flake
defined,
might
as
well
continue
to
use
that
paradigm
with
your
definition
of
new
job
sets
all
right.
So
we
give
this
a
a
quick
description
and,
let's
give
it
a
uri.
B
So
what
we'll
do
is
we'll
say
we'll
give
it
my
hydra
demo
uri.
Let's
also
take
a
look
at
what
this
project
is,
so
I've
got
a
repo
here.
It
just
says:
hydra
demo
ignore
these
two.
For
now
these
are
related
to
the
declarative
jobs,
but
this
is
just
a
simple
flake.
I
think
I
have
a
few
simple
jobs
here
defines
a
few
examples,
some
like
random
things,
to
kind
of
give
this
something
to
work
for
work
on.
B
So
you
define
this
using
your
flake,
your
eyes
that
should
be
relatively
simple
check
interval.
This
is
asking
hey
how
long
or
how
often
should
hydra
check
for
updates
by
default.
Hydra
is
just
gonna
check.
You
know
every
you
know.
Usually
you
give
it
like
a
few
minutes
or
something
like
that
say
200
seconds,
but
you
could
turn
this
around
and
make
it
so
that
it
receives
a
web
hook.
B
If
you
would
like
to
kind
of
have
that
a
little
bit
be
a
little
bit
more
live
and
not
pulling
again.
That
takes
a
little
bit
more
set
up
a
little
bit
more
configuration
to
set
that
up
scheduling
shares.
This
is
like
how
much
of
the
machine
it
should
have
access
to
in
terms
of
when
there's
contention
for
resources,
so
you
can
kind
of
put
some
number
in
there.
You
can
see
right
now:
okay,
there's
four
thousand
five
thousand
or
so
shares
in
use.
B
So,
let's
only
grab
like
100
of
those
whether
or
not
we
want
emails,
looks
like
we're
not
going
to
turn
that
on
for
a
moment
and
then
how
many
evaluations
to
keep
this
is
like
how
much
history
to
keep
around,
and
you
know
when
we
should
start
doing.
You
know
more
garbage
collection
of
that
work.
Obviously
doing
this,
for
you
know
too
long,
it's
gonna
kind
of
start
to
impact.
You
know
disk
space
and
database
usage.
B
You
know
for
something
simple
like
this:
we'll
just
do
like
three
or
so
all
right,
so
we
created
this
job
set
and
now
this
is
gonna,
go
download
that
project
and
when
it
comes
to
flakes
the
way
this
will
work
is
they'll.
Try
to
find
anything
that
is
defined
as
a
hydro
job.
We
have
a
few
hydro
jobs
to
find
here
and
we'll
see
if
that
works
out.
Okay,
so
looks
like
that
evaluation
succeeded,
we'll
go
over
to
the
jobs
column
and
see
what
they
are.
B
So
let's
kind
of
now
use
this
to
dig
into
kind
of
the
structure
of
hydra
itself.
So
when
we
have
at
the
top
level
you
have
things
called
projects,
this
is
kind
of
do
the
top
level
organization
you
saw
us
create
one
to
begin
with.
Once
you
dig
into
a
particular
project.
Now
you
have
job
sets.
We
called
ours
test.
B
B
You
know
all
the
different
variations
that
are
supported,
and
this
gives
you
a
little
bit
of
logical
grouping
that,
let's
kind
of
you
know,
ease
your
life
a
little
bit
and
then
so,
let's
go
into
one
of
these
jobs.
So
what
happened?
Here's
a
job
we
can
kind
of
get
a
little
bit
of
information
about
it.
There's
you
know,
charts
and
links
that
start
to
be
created,
there's
only
one
job
for
this
at
the
moment.
It's
not
super
helpful,
but
we
can
kind
of
dig
into
what
a
job
is.
B
Job
is
a
derivation,
the
the
nyx
subsystem
underneath
it's
gonna
build
the
thing,
and
then
you
know
the
results
of
that
are
displayed
here.
We
can
dig
into
a
little
bit
of
detail
for
this
one.
I
just
kind
of
grabbed
a
package
that
I
kind
of
already
exist,
so
that
wasn't
really
much
of
a
question
whether
or
not
would
succeed,
but
you
can
kind
of
get
a
little
bit
of
detail
for
it
here
on
the
inputs
column,
for
example.
B
B
I
like
the
build
dependencies
kind
of
graph,
showing
all
the
bookkeeping
taking
place
of
like
hey.
Here's
like
my
derivation
and
here's
all
the
different
things
that
it
took
to
build
it
all
the
way
down
and
tracking
and
seeing
the
whole
like
build
time.
You
know.
Graph
of
this
is
very
interesting,
at
least
in
some
sense
you
can
kind
of
dig
into
you
know
the
logs
of
each
of
those.
You
also
see
like
logs
of
some
of
these.
B
So
this
is
kind
of
a
good
kind
of
high
level
of
you
know
how
the
you
know.
Basic
usage
of
this
works.
The
nice
part
is
now
when
your
your
job
set
is
defined.
Let's
go
take
a
look
at
how
this
was
built.
This
uri
is
simply
the
pointer
for
it,
so
every
200
seconds
hybrid
will
go
to
this
uri
fetch
it
down
again
see
if
there's
any
changes
and
if
there
are
they'll,
go
this
whole
process
all
over
again
and
build
anything.
B
That's
been
changed,
so
this
is
kind
of
like
that
automatic
building
process
of
it.
That
kind
of
gives
you
a
little
freedom
from
having
to
like
just
go
and
build
everything
every
commit
yourself
and
now
we're
set
up.
So
this
is
kind
of
the
most
basic
usage
you
could
you
could
possibly
imagine
is
now
I
have
a
simple
project
or
a
job.
That's
run
all
right,
so
that's
that's
not
bad.
It
gives
us
something
to
work
with.
C
B
B
The
simplest
method
is
just
to
use
nyx
os
itself
because
we
have
a
service
module
defined
for
it,
and
so
you
can
use
that
going
into
a
service
module.
You
can
see,
there's
all
tons
of
definitions
in
here.
We
can
go
to
the
nexus
module
options
and
see
all
the
different
ways
you
could
kind
of
manage
and
configure
your
hydra
highly
recommend,
reading
through
and
understanding
these
things
and
trying
to
get
an
idea
of
like
what's
what's
possible.
B
Something
to
mention,
though,
is
that
the
you
know
there's
some.
You
know
documentation
about
the
configuration
of
hydra
itself
and
you
can
kind
of
go
through
the
documentation.
That's
in
you
know
it's
in
github.
I
think
it's
also
hosted
on
the
nexus
or
webpage
there's
also,
there
are
options
that
are
like
not
necessarily
easy
to
see
or
find
here.
B
So
just
the
fact
of
the
matter
is,
is
the
sometimes
the
easiest
way
to
understand
what's
possible
is
to
go
look
at
other
other
people's
configurations,
or
you
know,
reading
through
the
source,
sometimes
is
another
way
to
discover
new
options
that
you
know
you
weren't
familiar
with.
So
that's
kind
of
a
work
in
progress.
We
need
more
help
with
making
sure
all
that
is
well
documented
and
well-explained,
so
yeah
configuration
can
be
a
little
bit
annoying,
but
starting
with
the
nixos
module
options
is
usually
good
enough
to
get.
B
All
right,
some
of
the
issues
you
might
run
into
if
you're,
trying
to
host
your
own
hydra,
making
sure
that
the
hydra
you're
using
is
you
know
compatible
with
the
version
of
knicks
you're
using
so
there's
kind
of
hydra
nicks,
and
you
know
nick's
damon
relationships
that
need
to
be
you
know,
kept
track
of.
These
could
be
managed
with
a
nexus
module
option
called
services
hydra
package,
some
other
useful
things
to
mention
so
there's
build
machines
files.
B
So
if
you
would
like
to
declare
builders
that
are
going
to
be
dynamically
updated
or
if
you'd
like
to
kind
of
just
specify
a
lot
of
builders,
then
a
build
machine
file
is
kind
of
the
way
to
do
that.
This
allows
you
to
point
hydra
at
the
fact
that
there's
you'll
say
I
don't
know
15
different
builders
available
with
different
capabilities
and
here's
how
you
can
like
ssh
of
those
things
or
here's,
how
you
can
access
them
and
distribute
jobs.
B
There's
a
system
of
like
required
system
features.
This
is
kind
of
a
bit
more
advanced
if
we
want
to
like
push
particular
jobs
to
particular
kinds
of
machines.
I've
used
this
in
the
past
to
push
jobs
that
require
either
like
gpu
or
they
require
like
connected
hardware,
or
you
know
some
other.
Like
you
know,
nuanced
things
allows
you
to
have
a
little
bit
more
fine
grade
control
over
where
and
how
jobs
are
pushed.
B
We
use
this,
for
example,
to
if
there
are
certain
jobs
that
require
virtualization,
that's
kind
of
used
to
help
make
sure
that
those
jobs
go
to
those
machines
that
have
those
capabilities
versus
you
know,
let's
say
a
machine
that
cannot
do
that
sort
of
a
build
configuration.
Let's
go
into
a
little
bit
about
like
what
the
configs
I
mentioned
about
how
there's
some
difficulty
in
having
a
full
understanding
of
all
the
options
that
are
available
again.
We
need
help
with
that
mentioned
the
build
machine
files.
B
The
standard
approach
of
these
build
machines
tend
to
work.
Is
that
hybrid
kind
of
reaches
out
to
them,
rather
the
other
way
around
again,
you
could
work
your
way
around
that
with,
like
some
networking
and
some
configuration
that
you
have
to
kind
of
set
that
up
yourself,
then
there's
the
capability
to
do
run
command
hooks.
B
This
is
another
interesting
thing
where
usually,
if
you're
going
to
do
some
sort
of
a
build
as
part
of
like
a
project
testing
or
some
sort
of
like
ci
cd
at
the
end
of
the
conclusion,
you're
going
to
want
to
do
something
that
you
know,
it's
not
really
part
of
a
build,
but
more
like
a
notification
you're
going
to
want
to
tell
some
other
system,
hey,
I'm
done
or
hey.
This
was
successful
or
hey.
This
failed.
B
Let's
say
you
want
to
hack
on
hydra
itself,
so
the
there
are
actually
the
the
docks
for
this
are
are
pretty
good.
They
get
you
up
and
running
so
I'll.
Go.
Let's
go.
Take
a
look
at
that.
There's
some
pretty
good
hacking.md
docs
that
get
you!
You
know
started
in
terms
of
having
a
functional
and
running
instance.
That
is
local
and
there's
a
foreman
based.
B
You
know
proc
file
system
that
lets
you
kind
of
get
up
and
running
in
terms
of
all
the
databases.
You
need
the
servers,
you
need
it
orchestrates,
all
those
for
you
which
is
pretty
convenient.
So
if
you'd
like
to
kind
of
host
it
yourself
and
run
it,
you
can
do
so.
Let's
go
see
if
I've
got
my
yeah,
so
I
have
a
version
of
hydra
running
here.
Just
runs
on
localhost
and
you
can
kind
of
test
it
out
and
play
with
it
in
a
relatively
cheap
and
easy
manner.
B
B
B
Let's
go
look
at
just
hydra
demo,
this
one's
interesting,
because
right
now
we
made
it.
We
didn't
have
to
make
these
job
sets
ourselves.
Instead,
we
just
declared
them.
So
this
is
an
example
of
the
declarative
job
set,
so
we
can
take
a
look
at
how
that
is
created.
So
if
we
look
at
our
repository,
I
have
a
spec.json,
okay
and
using
a
you,
know,
relatively
simple
json
structure.
B
B
C
B
Let's
go
grab
a
look
at
that,
so
here
I've
got
job
sets
that
are
now
in
a
declarative
way.
So
this
will
start
to
show
a
little
bit
more
of
the
integration.
That's
possible.
For
example,
it
can
detect
that
hey
in
github
I
have
a
pr
and
that
pr
is
something
that
wants
to
be
given
its
own
job
set
and
then
any
sort
of
jobs
that
are
declared
inside
of
that
become
right.
Part
of
that,
so
you
can
see
hey.
B
Git
repo,
you
can
see
hey,
we
have
a
test
branch,
2
pr
looks
like
that
was
created
last
year
and
excellent
that
got
detected
and
that
got
turned
into
its
own
job
set.
So
that's
starts
to
show
some
of
the
capabilities
of
you
know.
Integration
that
we'd
like
to
see
managing
that
is
cr
is
done
by
this.
If
your
spec
json
has
a
slightly
different
structure,
you
could
point
it
at
an
input
to
say
hey.
I
want
to
have
a
height.
B
B
Here
you
can
kind
of
go
as
far
into
the
complexity
that
you
that
you'd,
like
again,
the
best
way
to
learn
about
this
at
the
moment,
really
is
to
kind
of
look
at
other
people's
examples
feel
free
to
look
at
you
know
this
one.
I
copied
a
whole
bunch
of
this
from
other
people
that
I
found
and
you
can
kind
of
take
a
look
at
what
it
does.
Roughly
it's
hey.
B
Take
a
look
at
the
pull
requests
that
the
the
perl,
the
github
pulls
plugin,
provides
iterate
through
them
and
create
new
job
sets
for
those.
Also,
if
I
have
particular
job
sets
that
are
going
to
be
used
for,
let's
say
exact
branches
that
I
care
about,
I
could
have
declared
those
in
here
and
then
you
create
again
a
json
that
looks
much
like
what
we
saw
earlier
and
that
that
will
populate
and
create
your
declarative
job
sets.
And
then
you
end
up
with
something
like.
B
B
You
have
to
be
a
little
bit
careful
right
if
you
want
to
expose
this
for
like
a
public
or
open
source
projects,
because
then
you
know
any
pr
to
your
project,
then
automatically
gets
a
job
created
and
then
now
there's
a
little
bit
of
issue
of
whether
you
want
to
allow
that
so
just
be
could
be.
Consider
the
fact
that
by
someone
creating
a
pr
they're,
then
kind
of
going
to
be
running
perhaps
builds
on
your
on
your
machine.
B
A
B
A
C
B
What's
something
that
might
be
interesting
is
to
have
this
sort
of
like
a
runner
that
can
you
know,
grab
this
work
and
then
push
data
into
hydra,
rather
than
it
be
kind
of
just
sitting
there
waiting
for
work.
So
it's
kind
of
a
slightly
different
paradigm
of
how
jobs
could
be
run.
You
know
those
are
some
some
possibilities.
Hydra
does
have
the
capability
to
do
more,
interesting
scheduling,
so
the
the
scheduling
capabilities
there
can
definitely
be
improved.
There's
there's
there's
room
for
work.
B
I'd
say
depends
on
what
people's
preference
are
for
for
getting
for
getting
into
collaboration,
so
there
is
a
matrix
channel
dedicated
for
for
hydra.
There's
also,
you
could
contact
people
over
discourse
or
even
just
going
to
like
if
you
just
want
to
work
on
just
prs
and
issues
and
get
jump
in
the
code
base.
You
can
also
go
to
github
and
go
kind
of
read
through
what
are
the
issues
there.
B
C
Okay,
great
and
then
I
have
a
question.
Maybe
you
know
the
right
one
to
answer
it,
but
I
wonder
if
there's
anyone
already
thinking
about
offering
such
hydra
style
ci
as
a
service
or
a
managed
solution,
so
that
people
don't
have
to
do
to
deploy
everything
themselves,
even
though
it's
quite
easy
to
do.
But.
B
Yeah,
so
there
are
a
few
kind
of
similar
features
out
there,
so
in
in
this
realm,
I'd
say
the
ones
that
to
take
a
look
at
are
things
like
nick
spilled,
net
hercules,
ci
and
cloud
hydra.
These
are
kind
of
the
variations
of
hey.
Let's
provide,
you
know
easier,
large-scale
mix.
Building
you
know
services,
those
are
probably
kind
of
the
best
ones
to
look
at
if
there's
any
other
ones.
I've
missed.
Please.
Let
me
know.
A
B
B
This
is
both
a
good
thing
and
a
bad
thing
right,
so
one
thing
it
would
expose
is
something
very
similar
to
what
you
would
see
when
you
look
at
the
let's
say,
a
flake
metadata
all
that
log
file
information,
a
feature
that
kind
of
has
been
kind
of
asked
about
or
talked
about.
There
are
some
patches
out
there
that
kind
of
start
to
implement.
This
would
be
to
opportunistically,
let's
say,
upgrade
to
those
lock
files
and
try
to
do
evaluation
jobs.
B
You
know
before
those
locks
are
actually
committed
to
a
repo,
that's
kind
of
one
aspect
of
it
or
if
there
live
you
have,
let's
say
you
have
a
repository
that
doesn't
have
any
locks.
You
purposely
don't
put
a
lock
in
there,
because
what
you
want,
perhaps,
is
for
hydra
to
generate
that
at
the
moment
to
grab
the
master
branch
or
you
know,
master
commit
from
everything
you
know
get
the
head
commits
and
then
pull
those
down
and
then
do
a
fresh
evaluation.
B
This
is
more
opportunistic
evaluation
and
job
building.
Some
of
those
you
can
kind
of
hack
your
way
around
them.
Some
of
those
kind
of
just
need
changes
to
hydra
itself,
but
a
lot
of
that,
I
believe,
is
just
waiting
for
that
whole
feature
set
to
go
out
of
experimental
and
to
be
stable
and
then
hydra
kind
of
can
kind
of
follow
along
and
make
that
user
experience
much
nicer.
So
it's
not
as
nice
as
as
you
could
imagine
it
being
there's
room
for
improvement.
A
B
B
Hopefully
this
all
works
out
nicely.
So
there's
links
to
that
hydra
hosts
that
are
going
to
be
always
like
the
latest
finished
evaluation.
If
you
have
a
particular
job,
there's
going
to
be
links
also
to
the
latest
successful
build.
So
by
querying
this
you
can
always
get
like
hey.
Give
me
the
latest.
That's
that's
built,
give
them
the
latest
that
has
artifacts.
B
B
So
you
can,
you
can
define
a
run
command
hook
and
a
run
command
hook.
Right
now,
look
I
think
I
have
doesn't
just
output
some
json,
but
a
run
command
hook
will
kind
of
run
at
the
conclusion
of
the
build
and
here's
where
you
can
start
to
do
impure
things
like
you
can
go.
Tell
another
system
hey.
I
finished
my
job
now
like
perform
a
deployment
or
something
like
that.
So
there's
a
that's
where
you
start
to
have
the
push-based
deployment
capabilities
defined.
B
Another
important
feature
that
you
can
do
with
hydra
is
to
say
at
the
conclusion
of
the
build
push
all
those
results
into
some
sort
of
binary
cache
and
that
binary
cache
can
serve.
As
you
know,
supporting
whatever
deployment
mechanism
you
have.
So
there
isn't
a
lot
of
opinionated
deployment
aspects.
You
can
build
several
different
ways
of
doing
it
yourself.
B
B
Ci
right
would
be,
I
believe,
mark
recall,
that's
that's
in
haskell,
so
it's
not
necessarily
a
hydra
rewrite
it's
kind
of
a
reimagining
of
how
to
do
it,
but
directly
taking
hydra
itself
and
doing
your
rewrite
I'm
not
familiar
or
aware
of
any
efforts
there
have.
There
are
a
lot
of
efforts
right
now
to
improve
the
quality
of
the
the
pearl
code.
So
that's
a
lot
of
what
graham's
been
working
on,
but
I'm
not
aware
of
a
full
like
let's
take
hydra
as
is
and
rewrite
it.
A
B
Legacy
I
mean
it's
just.
I
don't
believe
that
you
know
at
that
time.
When
you
know
hydra
was
originally
kind
of
worked
on.
These
features
were
added,
if
you
know
yemel
and
tamil
were
kind
of
in
use
at
that
stage.
So
I
just
think
this
is
just
a
question
of
history,
not
a
question
of
like
explicit
design
or
excluding
it
for
a
particular
reason.
B
So
this
has
to
do
with
this
aspect
of
you
know
having
dynamic
builders
possible.
Yes,
but
you
have
to
kind
of
hook
that
all
up
yourself
and
kind
of
make
it
all
work
and
get
that
machinery
going.
There's
no
kind
of
there's
no
button
that
says:
hey
enable
kubernetes
and
then
now
you
get.
You
know
you
get
everything
for
free,
so
possible.
B
Yes,
because
there's
a
lot
of
like
a
lot
of
the
control
you
need
to
do
so
is
exposed
to
you
but
like
making
it
all
work
and
hooking
it
all
up.
It
is
that
that
part
right
now
is
your
responsibility
at
the
moment.
That
does
take
a
little
bit
of
experience
and
expertise,
but
possible
yeah.
You
know
one
you
know
initial
way
to
to
do.
This
would
be
hey
if
you
have
a
builder,
your
kubernetes
defines
some
builders,
those
builders
as
they
get
stood
up.
They
register
themselves.
B
Basically,
we
add
them
to
that.
Build
machines,
file
that
we
talked
about.
That
is
going
to
be
dynamically,
read
and
looked
at
by
hydra,
to
add
and
remove
potential
builders
from
its
set
of
machines.
It
can
contact
and
then
at
that
point
if
hydra
can
basically
go,
distribute
those
jobs
to
those
kubernetes
machines.
It
will
so
the
that's
usually
going
to
be
the
primary
mechanism
for
like
auto
scaling
builders
up
and
down
is
that
build
machines,
file.
A
B
Yeah
I
had
an
example
once
where
I
had
like
raspberry
pi's
volunteering
themselves
as
builders
we
had.
You
could
have
like
you
know
if
you
want
macbooks,
if
you
want
stuff
from
cloud,
if
you
want
some
kubernetes
like
it's
in
that
sense,
it's
kind
of
the
world
is
your
oyster.
You
can
decide
to
do
lots
of
different
things,
but
you
just
have
to
kind
of
go
figure
out
how
to
get
that
done
and
that's
kind
of
where
the
some
of
the
usability
questions
lie
is
like.
B
A
B
So
not
necessarily
as
a
nix
maybe
plug-in
because
it's
like
so
the
the
nyx
plug-in
system
is
kind
of
more
designed
for,
like,
let's
add
built-ins
or
you
know,
let's
add
you
know
yeah
come
add
sub
commands
things
along
those
lines,
I
would
say
for
hydra's
kind
of
a
it's
like
an
inversion
of
control
based
on
kind
of
how
usually
you
know,
nix
is
going
to
run
and
schedule
its
builds,
so
maybe
not
necessarily.
As
a
knicks
plug-in
there
is
nyx
functionality.
B
B
These
things
are
kind
of
going
to
be
using
nicks
itself,
whether
or
not
we
can
abstract
away
something,
so
they
can
run
both
kind
of
knicks
and
hydra
style.
Scheduling
is
probably
I'd
say.
Maybe
I
mean
it's
interesting
idea,
but
I
think
we
have.
We
have
a
closer
alligators
to
the
boat
than
than
that
one.
Oh.
B
B
A
B
I
do
think
that
the
like
initial
user
experience
of
like
create
a
simple
job
set
is
absolutely
attainable,
and
so
I
encourage
people
to
do
so
either
to
self-host
it
or
you
can
use
the
ngi
zero
for
like
the
summer
of
next
participants
or
to
host
it
for
your
own
organization.
I
think
that's
also
another
viable
outcome.
A
A
So
that's
the
the
end
of
yet
another
very
insightful
lecture
series.
In
my
end,
I
hope
you
guys
enjoyed
it.
I
know
that
I
did
like
always,
but
the
next
lecture
does
not
yet
have
a
title.
It
will
be
announced
soon
enough.
So
keep
an
eye
out
for
that
on
on
this
course
and
the
community
calendar
I'm
sorry
for
sounding
a
little
bit
like
down
today.
I
haven't
slept
all
that
much
so
that's
why!