►
From YouTube: GitHub Actions in Jenkins
Description
Jenkins Contributor Summit June 25, 2021 - GitHub Actions in Jenkins Track
slides https://docs.google.com/presentation/d/1_8venS0I0MTqhpRixZhryVnMearVV4zcc5-FM77DDaY/edit?usp=sharing
A
A
A
Well,
the
jenkins
plug-in
ecosystem
provides
many
powerful
building
blocks
that
you
can
use
in
your
pipeline
to
do
a
certain
task,
but
they
typically
don't
extract
away
complex
problems
and
they
often
require
some
boilerplate
code
before
they
can
do
any
heavy
lifting
and
if
plugins
are
like
bash
commands,
then
the
jenkins
standard
library
is
like
the
pipe
operator
right
and
extended.
Functionality
is
great,
but
you
know
does.
Does
this
actually
solve
some
kind
of
problem?
A
A
So
the
shell
step
is
extremely
important
building
block
that
is
used
in
almost
every
pipeline
right,
but
that
doesn't
mean
it
couldn't
be
improved.
It
has
features
requested
by
the
community.
It
has
very
common
use
cases
and
some
quirky
behavior.
So
let's
jump
into
the
first
demo
and
see
what
improvements
we've
made
on
the
shell.
B
A
A
A
You
know
I've
gotten
into
several
different
jenkins
over
the
years
and
the
console
output
is
so
long.
You,
you
really
can't
you
know
it
slows
down
the
front
end
and
you
can't
find
the
useful
information.
So
this
is
the
exact
same
code
running
again,
but
now
we
don't
see
anything
in
the
console
except
for
what
I've
logged.
So
it's
hidden
from.
A
A
And
for
the
third
one
we're
actually
just
going
to
ignore
errors
completely
so
again
we're
running
the
same
kind
of
code
that
we've
just
ran
the
last
several
times,
but
this
time
we
don't
have
to
set
up
a
try,
catch
block
right,
we've
eliminated
the
try
catch
block.
You
know
this
is
handy.
If
you
already
know
you're
going
to
need
to
look
at
the
exit
code
and
there
we
go
so
we
get
the
standard
error.
The
standard
output
only
contains
or
the.
A
So
we
see
the
debug
output
and
you're
kind
of
getting
a
peek
of.
What's
going
on,
you
know,
behind
the
scenes,
and
one
of
the
things
that's
different
and
we're
trying
to
to
solve
is
most
of
the
tooling
that
we're
installing
relies
on
your
shell
sourcing,
either
bash
rc
or
bash
profile.
So
a
lot
of
tooling
that
you'll
install
these
days,
pi,
environment,
ruby,
environment,
any
of
those
toolings
like
that
are
messing
with
your
bash
rc.
A
And
you
know
it's
expecting
you
to
source
it
when
you
interact
with
those
tools.
So
we're
sourcing
bash
rc,
but
the
other
thing
that
we've
done
is
now
not
only
are
we
showing
the
output
of
the
command
but
we're
also
printing
the
actual
command
itself.
So
if
you
were
using
bash
variables
here,
this
would
be
handy
because
it
would
it
would
interpolate
those
variables
and
expand
them
for
you,
and
we
get
everything
else
that
we've
always
been
getting
the
standard
output
exit
code.
Things
like
that.
A
Http
requests:
it's
increasingly
common
to
interact
with
various
services
via
api
calls
in
our
pipelines,
so
taking
inspiration
from
python's
request
module.
I
created
a
simple
clone
that
would
make
it
easier
to
make
simple
http
requests
and
we'll
take
a
quick
look
at
some
example.
Requests
before
we
get
to
the
main
event,
which
is
github
actions.
A
So
the
code
here
again
is
going
to
be
pretty
much
the
same:
we're
going
to
import
the
library
and
import
the
the
classes
that
we
need
we're
going
to
make
a
git
request
to
http
bin
and
we're
going
to
pass
a
map
of
parameters
that
we
want
to
use
in
our
request,
and
some
of
these
are
kind
of
listed.
Where
are
nested,
where
we
have
one
parameter
as
a
list.
This
one
needs
url
encoded
because
there's
a
space
we're
going
to
make
that
get
request
and
then
we're
going
to
inspect
the
response
of
that.
A
We
got
back
a
map
of
headers,
but
what's
really
cool
is
we
got
back
a
response.json
which
is
already
a
groovy
map
so
that
that
string
body
that
was
returned
to
us
has
already
been
transformed
into
a
groovy
map
ready
for
you
to
use?
And
if
we
look
at
the
url,
you
can
see
that
it
auto
made
the
url
for
us.
We
didn't
have
to
manually
do
all
the
parameters.
The
parameters
was
a
map
and
it
figured
out
all
the
parameters
for
us
and
it
url
encoded.
Everything
for.
A
A
All
right,
so
why
would
you
want
to
run
github
actions
on
jenkins?
Well?
The
first
reason
just
might
be
that
it
has
an
amazing
abstraction
that
you
just
give
it
this
map
of
string
inputs
and
it
returns
a
map
of
string,
outputs
and
when
we
look
at
plugins
and
compare
them
to
plug-ins,
plug-ins
can
take
many
types
of
inputs
and
they
can
behave
in
many
types
of
ways.
A
Another
reason
is
that
actions
don't
need
to
be
installed
or
configured
ahead
of
time
and
depending
on
who
or
how
your
jenkins
is
managed.
This
could
be
a
huge
benefit
to
your
team
actions,
also
allow
developers
to
write
in
whatever
language
they
feel
the
most
comfortable
in,
and
this
is
probably
the
number
one
driver
behind
the
huge
explosive
actions
has
seen
in
the
last
year
or.
A
Actually
one
more
there
we
go
so
act
allows
you
to
run
your
github
actions,
workflow
file
locally.
It
even
comes
with
advanced
features
such
as
being
able
to
simulate
github
events
like
push
and
pull
requests
to
trigger
the
proper
workflow.
As
soon
as
I
found
this
amazing
project,
my
first
thought
was:
would
it
run
on
jenkins?
So
let's
try
it
out
and
let's
take
a
look
at
the
repo
that
we're
going
to
be
using.
So
this
is
an
example,
repo
it's
provided
by
the
act
team.
A
A
And
the
code
again
just
got
the
library
imported
so
so
far
we
haven't
needed
any
plug-ins,
except
for
maybe
the
the
node
plug-in,
which
comes
with
pipelines
to
run
the
shell
step.
Some
other
plug-ins
have
been
used
so
far
and
we'll
check
out
the
the
the
little
github
actions
demo,
repo
that
I
just
showed
and
then
we're
just
going
to
run.
Workflow
and
workflow
is
a
really
cheap
and
lazy.
Rapper
I
built
one
weekend,
and
so
it's
going
to
call
act
and
you
can
pass
it
a
string
and
anything
you
pass
to.
A
A
A
So
we
got
the
action
step
imported
and
this
line
right
here
is
needed
if
you're
doing
some
kind
of
like
docker
and
docker,
where
I'm
inside
of
a
docker
container
and
I'm
passing
my
socket
to
github
actions
right
and
I'm
creating
more
containers.
So
if
you
aren't
in
doing
docker
and
docker
type
stuff,
you
don't
have
to
worry
about
this,
but
it
is
needed
to
make
this
solution
work.
A
Is
the
same
thing
that
you
would
pass
into
a
workflow
step,
so
I'm
just
giving
it
the
name
which
is
a
generic
name,
that's
displayed
when
it's
run,
I'm
giving
it
a
uses
which
points
to
the
action
on
docker
that
I
want
to
use
and
the
version
that
I
want
to
use.
So
it's
basically
a
github
slug
with
the
the
username,
the
repo
name
and
then
some
kind
of
reference
and
then
with
with
I'm
passing
it
any
parameters
or
variables
that
I
want
to
use
and
then
that's
it.
A
A
A
C
A
So
yeah
we
we
check
out
the
the
action
it's
a
docker
container,
so
we
build
that
container
locally.
Then
we,
you
know
we
have
to
map
in,
like
our
current
directory
into
the
container,
there's
a
whole
like
or
aws,
there's
a
whole
github
specification
document
on
how
to
build
an
action
correctly,
and
then
we
just
run
it
hello,
docker
action,
and
then
we
get
this
map
back
and
one
of
the
things
that
returned
was
an
output
called
time
right
now.
A
This
was
pretty
cool
and
it
didn't
take
me
that
long
to
build
but
turns
out
actions
support
several
flavors.
So
we
it's
not
just
docker
that
we
have
to
be
able
to
run.
We
also
have
to
be
able
to
run
javascript.
So
there's
a
javascript
action
and
it
looks
pretty
much
the
same
thing.
It's
just
going
to
run
the
hello
world
action.
These
are
by
the
way,
these
actions
that
I'm
running
are
just
provided
by
they're
they're
used
in
the
tutorial
from
github
for
how
to
build
action.
A
C
A
A
Yeah
here
here
it's
always
a
container,
so
what
I
did
for
the
javascript
one
is
I
I
made
it
behave
like
a
container
so
instead
of
like
actually
installing
node
locally,
which
I
think
they
already
have
like
node
installed
on
their
runners,
I'm
just
wrapping
wrapping
whatever
scent,
whatever
repo
set,
I'm
just
injecting
that
into
my
own
node
container
and
then
running
it.
So
here
we
go
and
it
works.
A
It
works
behave
except
for
they
put
this
event,
payload
thing
which
is
not
in
not
in
the
docker
version,
but
it's
in
their
javascript
version,
but
it
still
gives
us
the
time
of
the
build
and
then
there's
a
third
one.
There's
a
composite
action
and
a
composite
action
is
actually
quite
complicated.
It's
an
action
that
can
run
like
other
action
steps,
but
mainly
when
people
use
it
they're
using
this
shell
they're
using
run
and
they're
running
bash
commands.
A
So
in
this
example
we're
going
to
pass
it
some
bash
to
run,
and
it's
going
to
set
an
output
in
the
map
of
outputs
that
are
returned
and
the
name
will
be
test
and
the
output
will
be
some
value.
But
this
could
be
anything,
and
I
actually
really
like
this
one,
because
you
could
take
a
really
long,
complicated
legacy
bash
script
that
your
company
has
and
you
can
add
some
outputs
to
it,
because
a
lot
of
times
that's
what
we
just
want.
A
We
have
multiple
spots
in
the
bash
script
and
we're
just
like
man
I
wish
I
could
have
whatever
this
output
is
into
an
easy
to
use
variable,
and
so
now
that
makes
it
a
lot
easier
because
you
can
inject
it
into
a
map.
So
here
we
go.
We
felt
I
think
I
ran
the
wrong
one.
Did
I
run
both
or
just
one
sorry
about
that.
C
All
right
actually
advantage
of
this
approach
that
you
can
also
use
search
engine
spiralization
features
yeah
because
yeah
you
still
have
full
control
and
yeah.
Maybe
one
question
about
the
implementation.
So
basically
you
run
everything
on
the
agent
side
right.
So
when
you
execute
within
no
context
it's
a
agent,
it's
not
execution.
Think
on
the
controller.
A
A
A
We'll
run
the
first
one
again
the
docker
action
again,
but
we'll
take
advantage
of
that
pipeline
log
level
for
debugging,
because
again
most
of
the
things
we
build
respect
that
and
can
change
the
functionality
of
what's
happening.
I
think
for
this
one
I
haven't
implemented
where
it
won't
delete
the
running
container.
A
It'll
leave
the
container
up
for
inspection,
but
that's
something
that
I
want
to
implement
in
the
future
is
when
you
run
it
in
debug
and
if
you
run
debug
during
this,
build
it'll
keep
this
container
up
so
that
you
can
access
it
and
mess
with
it.
So
what
we're
seeing
in
green
is
like
it's
looking
at
the
metadata
file
and
the
metadata
file
tells
you
how
to
run
this
action.
A
So
it
says:
hey,
I'm,
expecting
these
inputs
and
here's
the
default
value
and
here's
the
outputs
and
what
they
are
and
here's
how
to
run
me-
and
this
is
the
args
that
I
want
so
we're
we're
parsing
this
and
handling
all
this,
and
then
here's
the
build,
the
build
log
and
the
actual
script
that
we
run
and
then
then
the
output.
So
if
we
come
back
and
hit
replay,
we
should
be
able
to
remove
like
who
degree
I've
actually
never
did
this.
So
probably
shouldn't
do
it
live,
but
it
should
say
hello
world.
A
A
C
So
for
me,
as
an
individual
contributor,
I
would
be
definitely
interested
to
promote
that
and
I
definitely
see
many
users
adopting
this
approach
even
on
the
jenkins
infrastructure,
because
we
have
an
open
question.
For
example,
how
do
we
integrate
release
drafter
with
jenkins
pipelines?
We
have
our
own
solution,
but
I
think
that
we
could
just
use
a
library
to
trigger
this.
It
have
action
though
it
actually
is.
The
one
question
is
about
passing
credentials
and
secrets.
C
A
So
I
haven't
looked
into
using
any
kind
of
credentials
yet,
but
you're
definitely
going
to
like
most
github
actions
is
going
to
want
to
hit
your
the
github
api
and
do
that
with
it.
So
I
haven't
tackled
that
yet,
but
I
was
going
to
test
it,
I'm
pretty
sure.
For
now
you
could
wrap
that
in
with
environment
right
or
like
with
credentials
right,
yeah.
C
A
C
A
Yeah
so
the
license,
I
think
I
picked
like
gpl
v3,
that's
probably
like
one
of
my
weakest
things
was
trying
to
understand
licensing
and
things
like
that.
But
yeah.
I
tried
to
pick
one
that
made
it
easy
for
anyone
to
use
and
take,
and
I
think
the
only
downside
to
gpl
is
that
you
can't
bundle
it
with
other
code.
So
maybe
that
affects
what
you
were
saying
about
getting
it
integrated
with
another
project,
but
we
can
probably
just
change
it
and
then
and
then
for
contributing
there's
a
contributing
doc.
A
I
just
wrote
it
and
I've
never
tried
it.
So
I'm
not
exactly
how
close
it
will
be
to
your
experience,
but
it
should
be
pretty
easy
to
get
up
and
running
because
the
project
itself
is
actually
using.
You
know
it's
using
gradle,
but
it
also
uses
pre-commit
in
python.
So
actually
the
testing
setup
is
quite
weird
because
I'm
not
like
having.
I
don't,
have
a
really
strong
background
in
java,
so
gradle
and
maven
I
try
to
stay
away
from,
but
I
wasn't
happy
with
the
there's.
A
The
two
main
testing
frameworks
and
jenkins
right,
there's,
jenkins,
spock
and
then
there's
another
jenkins
like
pipeline
or
something
I
can't
remember.
I
I
didn't
neither
one
of
those
would
do
the
things
that
I
needed
to
do
and
because,
like
for
instance,
I
have
the
logging
thing
right
and
I
needed
to
test
like
did
the
logging
work,
but
from
a
user
perspective.
So
none
of
those
returned
to
be
like
the
raw
logging
of
the
actual
job.
A
A
So
what
I've
done
is
I
have
my
tests
written
out
for
each
package
in
each
class
and
then
what
I'm
doing
is
I'm
starting
a
jenkins
file
runner.
So
I
have
this
pi
test.
This
thing's
got
a
fixture
is
what
it's
called
in
pi
test,
but
this
is
just
passed
into
my
test
and
it's
a
function
and
it
acts
like
a
decorator.
So
it
returns
a
function,
but
it's
returning.
A
This
run
test
function,
but
all
it's
doing
is
creating
a
container
running
jenkinsfilerunner,
so
it
creates
the
container
the
container
is
running
and
it
passed
that
container
back
to
the
test
function.
So
here's
the
run
test
and
what
I
do
is
I
pass
it
the
path
to
the
job
I
want
to
run,
so
all
of
my
tests
are
actually
defined
as
real
jenkins
jobs
that
can
run
on
any
jenkins.
A
So
you
can
take
any
of
my
my
test
jobs,
throw
them
into
your
jenkins
after
you
install
the
jenkins
standard
library
and
they'll
all
run
and
pass
so
yeah.
I
get
the
container
running
and
then,
when
you
run
run
test,
it's
just
running
the
exec
command
on
that
existing
container
right
and
it's
it's
pointing
to
the
job
path
and
running
that
single
job.
So
I'll
show
you
the
test.
A
So
that
makes
a
little
bit
more
sense
and
then
I'll
show
you
what
the
actual
tests
look
like,
because
the
python
is
just
basically
passing
in
the
name
I'll
show
you
the
logging
one.
So
it
makes
a
little
bit
more
sense
why
I
needed
such
a
weird
testing
environment.
So
here
my
container
is
that
function.
I
just
showed
you
and
when
I,
what
I'm
passing
to
it
is
the
path
to
the
job
that
I
want
to
run.
So
here
it's
gonna
run
logging
logging
example
and
the
job.
B
A
C
D
C
Yeah,
I
really
like
this
approach,
though
we
are
still
yet
to
implement
the
junkies
file
runner-based,
test
automation,
and
actually
there
was
even
a
session
contentively
scheduled
for
the
today's
summit
about
testing
pipeline
libraries.
I
believe
with
this
changes
file
runner,
but
we
haven't
got
enough
forum
to
get
this
session
running.
A
A
I
found
jenkins
foul
runner,
but
I
struggled
with
getting
it
running,
so
I
actually
put
this
away
for
like
six
months
and
then
I
had
some
time
around
thanksgiving
holidays
in
the
u.s
and
I
went
back
to
work
on
it
and
got
got
disclosed,
strung
together
and
yeah.
So
this
is
this.
Is
that
same
job?
The
the
logging
example-
and
I
use
this
as
like
documentation
on
how
to
use
things
and
as
tests
and
so
like.
I
got
this
weird
stuff.
A
You
know,
like
you,
have
to
worry
about
pipeline
cps,
so
I
I'm
always
triggering
like
different
cps
stuff,
like
shell
scripts
at
the
beginning
and
end
of
my
test,
to
make
sure
that
anything
I
write
is
going
to
be
cps
compliant,
it's
not
going
to
mess
anyone
up,
but
here's
that
logging
logic
and
the
logging
logic
is
kind
of
boring.
Some
of
the
other
logic
that
I
have
is
a
little
bit
better
so
like.
A
A
Actions
actions
is
the
most
recent
code.
I
wrote
so
yeah,
some
of
it
I'm
actually
trying
to
write
unit
tests
as
well.
So
I
got
the
example:
jobs
which
are
like
my
functional
test,
but
then
like
I'll,
come
in
here
and
I'll
create
a
little
tiny
test
for
individual
functions.
So
you
know
is
this
returning
is
this
one
is
if
it
throws
the
right
air
right.
So
did
you
put
something
in
that
you
shouldn't
have
put
you
know
we
can
test
for
that.
A
A
So
it's
a
weird
it's
a
weird
testing
workflow.
It
doesn't
take
that
much
to
get
set
up.
So
if
you
have
docker-
and
I
think
I
got
everything
in
like
just
a
requirements
file
inside
the
test
directory
yep-
so
if
you
could
run
pip
install
in
a
virtual
environment,
you
can
run
pi
test
and
it
should
run
all
these
tests
and
they
should
all
pass,
and
I
I
have
a
docker.
So
by
default
it
uses
my
docker
image,
but
there's
steps
in
the
contributing
guide.
A
A
A
C
A
Yeah
yeah,
I
I
I
stripped
out
a
lot
of
that
and
got
it
down
to
like
700
megs,
but
I
think
it
could
be
smaller.
I
just
mean,
like
I
mean
you
should
talk
later
about
that
repo
and
in
the
readme
and
the
instructions
in
it,
because
I
have
some
ideas
on
how
to
make
it
super
easy
for
anyone
to
use
thinking
file
runner.
I
think
it's
kind
of
complex
right
now,
if
you're
not
from
java-
and
you
don't
know
what
wars
are
and
you
don't
know
how
to
build
gradle
build
it's
quite
complicated.
C
C
D
C
C
We
work
together
in
a
team.
This
framework
is
basically
built
around
custom
work
package,
focus
images
and
it
uses
sh
unit
tool,
but
it
was
built
for
very
old
versions
of
genghis
file,
runner,
which
are
quite
heavy,
so
this
framework
is
also
quite
heavyweight,
and
I
was
when
I
was
rebuilding
unit
testing.
I
moved
the
most
of
the
tests
from
this
framework
to
actually
just
unit
tests.
C
So
currently,
if
you
go
to
gengxis
file
runner,
what
I
have
here
give
that
yeah.
So
it's
still
incubating
project
but
yeah
whatever.
So
there
is
slim
packaging
right
now
and
it's
really
slim.
So
it's
gets
your
140
megabyte
images
and
you
still
can
run
tests
for,
for
example,
for
vanilla
package.
What
you
can
see
here-
it's
probably
not
the
stator
for
the
earth
implementation,
but
still
so
there
is
a
smoke
test
and
actually
this
smoke
test
allows
to
connect
to
jenkins
instance
and
to
verify
everything
using
standard.
C
The
jenkins
test
harness
framework,
but
you
can
also
run
a
jinx
file
runner
with
all
the
features
like
gcask
etc.
Just
by
passing
such
configuration
files,
obviously
it
can
be
prettified,
but
it's
a
junior
test
at
the
moment,
so
for
some
kind
of
tests
it
might
be
easier
to
do
it
this
way
or
but
yeah.
I
understand
that
for
real
integration
tests
it
might
be
actually
preferable
to
have
your
framework.
C
Maybe
you
have
some
equivalent
of
jinx
folder
under
test
framework.
Maybe
jenkinsfile
rather
test
the
framework
to
decision
which
would
actually
be
built
around
a
more
complicated
test
framework,
because
this
one
needs
to
be
reworked
for
modern
packaging,
so
custom
word:
packager
now
is
optional
for
jinx
file
runner
and
the
customers.
Packager
still
needs
to
be
updated
to
support
the
recent
versions
sufficiently.
C
I
cannot
do
that
because
of
let's
say
non-technical
reasons,
but
somebody
can
build
it
around
that,
so
our
own
slim
packaging
we
currently
integrate
the
agency's
plugin
manager
ran
inside
the
image
it's
cli
tool,
so
you
can
actually
build
a
test
framework
around
that
and
make
it
generic
enough.
So
what
you
did
for
your
library,
but
maybe
something
we
could
reuse,
for
example,
for
jenkins
pipeline
library,
I'm
not
sure
whether
you
have
seen
this
project.
C
No.
So
jenkins
filter
we
have
our
own
pipeline
upgrade,
which
we
use
well
surprise
for
testing
for
jenkins.
So
it's
what
reduces
our
pipelines
to
one
liners
for
building
standard
pipelines,
standard,
plugins
and
yeah.
It's
actually
quite
complicated
inside
at
the
moment.
So
victor
has
invested
a
lot
of
time
into
creating
jenkins
pipeline
unit
based
test,
but
it's
a
jinx
pipeline
unit.
We
don't
have
integration
tests
there
at
the
moment
and
yeah
I
made
an
attempt
actually
to
integrate
jinx
just
hardness.
C
C
Oh,
I'm
blind
so
yeah,
basically
the
point
here
that
it
required
some
patches
on
the
the
library
side,
but
it
allowed
to
actually
run
a
jinx
file
runner
test
and
I
believe
that
he
had
a
demo
for
that
yeah
so
make
file
which
basically
runs
integration
tests
in
this
library.
So
here
you
can
see
that
I'm
using
jenks
fellow
runners
test
framework.
So
it's
basically
around
sh
unit
2-
and
this
is
was
quite
a
problem
for
me
because
he
requires
native
docker,
etc.
C
So
it
requires
quite
heavy
resources
to
test
it
and
I
would
rather
prefer
something
lightweight
without
maybe
even
docker
at
all,
but
yeah.
This
is
a
framework
how
it
looks
like
in
practice.
So
it
was
running
just
two
smoke
tests
is
doing
some
setup
and
it
was
testing
the
build
plug-in
step.
So
it
was
basically
building
the
image
with
maven
result
tools
embedded
to
emulate
our
searching
sio
environment.
C
You
can
see
that
I
also
had
to
keep
windows
built,
so
I
had
to
patch
actually
our
production
to
test
it,
but
it
was
running
so
I
was
able
to
do
integration
tests
for
while
using
this
old
framework,
and
I
think
that
with
modern
approaches
it
could
have
been
much
easier
because
sh
unit
2
is
designed
for
testing
brush
and
it's
not
exactly
the
most
friendly
framework
for
testing
in
general,
so
yeah.
I
think
that
your
framework
could
fit
this
use
case
quite
well.
C
C
D
D
D
Have
you
thought
about
the
files
we'll
leave
always
there
as
any
github
workflows
and
the
pipeline
to
be
consuming
these
files,
rather
than
defining
them
in
the
declarative
file?
Sorry,
in
the
pipeline
itself,
like
consuming
these
files,
that
are
more
probably
easy
to
read
from
the
user
point
of
view,
rather
than
adapting
the
changes
in
the
pipeline
itself,
if
it
makes
any
sense.
A
Yeah,
I
think
I
was
I
was
kidding
you
you're
talking
about
like
almost
hiding
the
jenkins
from
the
user
right
and
just
having
them
worry
about
the
the
workflow
file
yeah.
I
think
that
would
work.
I
mean
that's
kind
of
how
this
whole
thing
came
about.
I
was
working
for
a
machine
learning
team
that
works
on
self-driving
cars
and
I
think
they
were
a
little
bit
unhappy
with
their
infrastructure
team
and
some
of
the
things
with
jenkins.
So
they
were
wanting
to
run.
A
A
Was
trying
it
and
it
wasn't
that
hard
to
put
together.
So
I
think
that's
a
use
case.
I
mean
there's
going
to
be
people
that
are
kind
of
stranded
and
they
feel
like
they're
straining
on
jenkins
and
they
want
to
move
somewhere
else.
We
can't
and
now
we
you
can
bring
some
features
to
them
that
that's
easier
for
them
to
use,
and
then
I
think,
on
a
second
like
the
other
thing
might
be
well,
maybe
we
just
want
to
make
it
easier
for
our
users,
so
we
can
create
a
couple.
A
You
know
a
generic
library
function
that
just
checks
out
the
user's
code
and
then
runs
the
user's
action
right.
That's
all
we
have
to
maintain
in
groovy
and
then
they
can,
you
know
trigger
it
from
their
from
their
from
their
github
and
run
the
job.
So
I
think
that's
part
of
it.
For
me,
I
wanted
to
just
reach
out
and
leverage
a
action
here
and
there,
where
maybe
I
couldn't
find
the
correct
plug-in,
but
I
could
find
the
action
and
I
was
like
man,
if
only
I
could
just
run
that
action.
A
I
already
have
this
pipeline
built.
It's
already
really
nice
and
robust,
but
I
just
need
that
one
action
and
I
really
just
don't-
want
to
recreate
it
all
in
groovy,
especially
if
it's
like
for
one
one.
One
thing
that
I
know
I'm
never
going
to
use
again
so
yeah
there's
a
couple
different
use
cases
and
I
certainly
hope
people
use
it
because
right
now,
it's
like
me
and
two
friends
so.
A
A
Some
people
in
that
call
were
like
we'll
all
be
gamble,
pipelines
and
real,
simple
pipelines
in
the
future,
and
then
there's
people
like
me,
I've
worked
with
a
lot
of
legacy
stuff,
a
lot
of
complicated
stuff,
long
learning,
ml
builds,
and
for
me
I'm,
like
you
know,
I
I'm
not
sure
I
want
to
do
everything
in
bash
enamel.
You
know
I
I
kind
of
like
having
the
full
term
and
complete
language
at
my
disposal,
and
I
know
I
can
build
anything.
A
A
But
when
you
run
it
all,
the
steps
are
built
in
some
kind
of
high
level
language
that
that
developer,
wanted
and
that's
definitely
part
of
its
growth
was
one.
It
was
very
close
to
your
source
code.
So
it
makes
it
easy
to
see
the
build
and
have
visibility
into
the
builds
and
then
two
they
can
any
developer
can
write
whatever
action
they
want
in
the
language
or
their
choice.
But
I
don't
think,
like
I
don't
think
we're
going
down
a
road
where,
like,
if
jenkins,
doesn't
switch
to
bash
it's
obsolete,
bastion
yammer.
A
Just
because
if
you
look
at
vehicles
you
know
we've
had
over
100
years
now
for
vehicles
to
just
look
like
one
shape
and
they
don't
so.
You've
got
different
different
vehicles
right,
different
cars,
trucks,
vans
buses
for
different
different
needs,
and
I
think
that's
what
we'll
see
is
when
you're
doing
simpler
pipelines
like
kubernetes,
where
you
can
deploy
with
cubectl
and
your
pipeline's,
not
that
complicated.
A
You
can
probably
do
everything
in
the
m1
batch.
I've
had
these
really
crazy
pipelines
that
you
know
you're
you're,
building
applications
and
then
you're,
triggering
builds
and
or
a
bunch
of
other
builds
for
a
bunch
of
other
teams
in
the
same
organization
to
make
sure
that
their
stuff
works
with
your
application
and
then,
once
all
those
results
come
back.
You
know
you're
looking
at
test
results
and
they
have
to
be
a
certain
amount
and
then
you're
going
out
and
you're
making
a
servicenow
ticket,
and
you
have
to
wait
till
the
rib
board.
A
B
A
Yes,
with
a
plug-in
so
yeah
in
the
readme,
I
talked
about
how
to
make
your
jenkins
look
like
my
jenkins.
So
it's
the
simple
theme
plugin
and
it
basically
allows
you
to
manipulate
the
css
in
the
gui
and
so
there's
two
classes
pipeline,
hyphen,
annotated
and
pipeline
hyphen,
new
node
and
I
just
set
display
to
none
and
then
they
disappear.
So
if
you
like,
go
in
your
jenkins
log
right
now
and
like
you
know,
hit
f12
to
bring
up
the
dev
tools,
you
can
set
those
classes
to
display.
A
None
and
you'll
get
a
really
clean
output.
Yeah.
I
one
of
the
things
that
kills
me
is
opening
up
someone's
jenkins
log
and
it's
like
thousands
and
thousands
of
kilobytes,
long,
maybe
30
or
50
or
100,
and
the
jenkins
gooey
nearly
crashes
and
you're
trying
to
scroll
through.
You
know
some
giant
c
make
bill.
Looking
for,
like
the
one
thing,
that's
important!
That
kind
of
stuff
kills
me.
A
So
when
I
teach
jenkins,
I
try
to
teach
people
that
you
know
when
you,
when
you're
trying
to
build
this
pipeline
you're
the
user
like
make
it
nice
for
yourself,
because
no
one
else
will
so
make
these
usability
features
that
that
help
like
the
debug.
When
you
flip
that
log
level
to
debug
you
should
your
tools
should
behave
differently.
So
I
have
a
bunch
of
stuff.
A
I
haven't
added
to
the
library
because
of
time
I
actually
just
got
the
testing
kind
of
stuff
working
in
february,
and
I
added
a
couple
things
and
then
I
started
working
on
the
github
action
stuff
like
two
months
ago,
but
I
have
a
lot
of
stuff.
I
want
to
add
to
the
library
things
like
I
wrote.
I
have
a
terraform
client
that
deploys
terraform
code
super
sweet.
You
know
things
like.
A
I
have
a
packer
wrapper
that
will
allow
you
to
build
packer
amis
and
when
you
turn
on
debug
and
run
the
job,
packer
will
not
delete
the
ami
when
it's
done
the
image
when
it's
done
like
the
running
one.
So
if
you
have
a
failed
build,
you
turn
on
debug.
You
run
it
a
second
time
and
the
image
stays
up,
so
you
can
ssh
into
it
and
figure
out.
B
Unfortunately,
I
thought
there's
a
way
to
hide
outputs
from
selected
steps
right
so
from
regular
pipeline
code.
I
actually
won
these
messages,
but
we
have
some
pipeline
functions
that
uses
maybe
echo
step
a
lot.
Maybe
is
unix
step
a
lot
and
you
see
this
wall
of
text
and
the
logs
it's.
It
can
become
it
it's
cluttering.
It's
can
be
really
confusing.
So.
A
A
Found
it
years
ago
years
ago,
and
because
it
wasn't
published
to
jenkins-
and
I
you
know
I
didn't
know-
I
didn't
even
know
how
to
pull
it
down
locally
and
build
it
and
then
install
it
to
jenkins.
So
I
never
used
it,
but
it
was,
it
did
work
and
there
was
like
you
know.
There
was
like
issues
where
people
were
like
hey.
You
should
publish
this,
I
don't
know
the
name
I'll
google
search
it
and
maybe,
if
I
find
it
later,
I
will
call.