►
From YouTube: LabFlow demo
Description
A
Hello
there,
I'm
mikhail
from
the
configure
team
I'd
like
to
show
you
something
that
I've
built
it's
a
proof
of
concept,
for
an
idea
to
allow
the
ci
user
to
construct
the
share
pipeline,
which
is
a
graph
of
jobs
using
the
program
so
yeah.
I
won't
go
into
much
detail
of
how
we
got
here.
Please
like
read
the
readme
and
follow
the
links.
A
I
just
wanted
to
record
a
brief
overview
and
show
some
pictures
that
the
program
generates
so
problems
that
we
are
trying
to
solve
here
are
well
described
in
this
blueprint.
That
is
being
worked
on
by
someone
else
which
I
stumbled
upon
accidentally
like
recently
like
a
week
ago,
and
so
the
problems
are.
A
We
have
two
two
jobs,
some
arguments
and
the
second
job
actually
depends
on
the
first
one
and
we
can
try
to
run
it
and
it
actually
generates
a
graph
into
a
file
that
is
a
visualization
of
the
graph
and
here
here
it
is
so
there's
a
bit
of
nesting
going
on
here
and
I'd
like
to
explain
that
a
little
bit,
so
this
arrow
is
depends
on
relationship.
So
this
thing
depends
on
that
thing.
Now
this
thing
is
an
action
in
this
case.
A
A
A
This
is
the
simplest
thing
we
can
have.
I
guess
so
what's
interesting
here,
you
can
see
that
we
can
define
types
for
the
arguments
and
we
use
something
called
schemas
to
define
types
and
they
compose
this
thing.
Arguments
is
a
list
of
which
item
of
the
list
is
a
string,
and
here
we
can
assume
the
arguments
using
the
context
passed
here
in
address
image.
This
thing
passed
to
the
front
container
and,
and
so
on.
This
is
retrieving
the
arguments
if
that
defaults
into
an
empty
list.
A
A
A
A
A
This
this
function
gives
us
a
setter,
a
way
to
set
the
future,
and
then
we
instantiate
an
action
which
will
publish
the
docker
image,
and
we
tell
it
where
to
write
the
name
of
the
published
image
by
setting
an
environment
variable
to
the
file
name
of
the
setter,
and
then
this
actually
creates
an
action,
and
we
we
get
the
set
getter
for
the
future
by
calling
the
setter
function.
Price
interaction
to
it
so,
like
you
know,
set,
gives
you
a
getter.
A
A
A
Like
it
validates
that
you
are
constructing
the
correct
thing
that
you
set
in
the
right
attributes
to
the
correct
values-
and
in
this
case
each
image
is
an
object
that
has
a
single
attribute
image
and
it's
a
future
getter.
So
it's
a
way
it's
a
way
to
say
that
image
is
that
getter
part
of
the
future,
so
that
you
can
use
it
to
get
the
value
that
will
be
produced
in
another
side,
job,
basically
in
another
action.
A
A
Hopefully
that's
more,
that's
clear,
then
yeah,
that's
our
publishing
job,
we
record
here.
It
constructs
an
action
in
the
future
and
returns
a
list
of
objects
which
contains
each
each
of
those
contains
the
getter
of
the
container
image
name.
So
then,
we
call
this
scan
function,
which
we
import
from
this
library
and
that's
where
these
things
are
defined
and
scan
is
also
a
step,
so
it
can
generate
one
or
more
actions
or
maybe
zero
actions.
A
A
A
It's
like
pretty
straightforward:
it
scans
the
list,
this
list
to
scan
just
iterate
and
then
in
each
item
of
the
list.
We
take
the
value
of
image
list
and
then
we
iterate
this
images
attribute
and
for
each
image
in
that
list
we
create
an
action
to
scan
it.
So
this
is
the
docker
image
that
will
be
used.
A
A
A
It
depends
on
on
this
future
for
the
value
it
will
use
the
value
here
in
the
arguments.
This
is
how
that
knows
what
to
depend
on,
and
let's
change
it
to
be
more
interesting.
So
let's
say
we
have
more
images.
We
want
to
scan,
we
publish
more
images
and
we
depend
on
all
three
for
the
false
should
be
sequential
okay.
A
A
A
A
We
get
proper
error
messages
because
we
validate
all
the
arguments
when
we
are
constructing
the
graph.
We
don't
need
to
actually
run
the
build
to
see
that
there
is
a
problem
like
your
environment.
Variable
is
a
string
of
characters.
One
should
be
an
integer,
a
string
with
an
integer,
let's
say-
or
you
know,
a
boolean,
an
integer
and
so
on
so
doesn't
fix
all
the
problems
doesn't
prevent
all
the
problems,
but
it's
a
good
thing.
I
think.