We'd
like
to
talk
about
taking
a
JAAB
at
add-in
building,
is
what
we're
calling
Project
JAAB.
We're
using
GitHub
actions
to
streamline
the
deployment
of
JMP
tools.
A
little
bit
of
overview
about
what
we
want
to
talk
about
today
talks
about
the
utilization
of
JSL,
and
it
is
continue
to
expand
as
versions
of
JMP
has
come
out.
There
arises
an
increasing
demand
for
better
control
and
enhanced
maintenance
of
these
tools
as
more
and
more
tools
are
being
managed
to
help
make
people
more
efficient.
Previously
involved
in
this,
there
were
limited
options
that
really
integrated
both
the
version
control
aspect
of
it
as
well
as
the
deployment
of
the
add-in.
Entering
Project
JAAB.
Hopefully,
with
this
we
believe
it's
going
to
be
a
cutting-
edge
initiative
using
GitHub
Actions
to
do
something
that
is
analogous
to
what
GitHub
actions
are
intended
for,
but
doesn't
seem
very
common
currently
in
their
sphere.
We
hope
this
is
going
to
enable
seamless
packaging
and
deployment
of
add-ins,
making
a
diverse,
robust
system
to
really
help
out
JSL
coders
everywhere.
In
the
beginning,
the
Add-In Manager
really
changed
the
game
for
us.
I
say
that
because
I
had
local
source
files
coming
in.
I
then
could
just
simply
export
them
to
a
folder
and
come
in
with
Add-In Manager.
This
is
something
that
was
built
by
Justin
Chilton,
a
JMP
employee,
and
this
really
streamlined
the
process
because
when
I
use
this
add-in,
I
was
able
to
get
a
package
JMP
add-in,
I
was
able
to
get
version
archival,
as
well
as
a
network
deployment.
It
would
place
the
add-ins
in
specific
network
folders
depending
on
various
metadata
surrounding
that
file,
and
also
kept
track
of
what
I
had
published
and
when
I
build
certain
add-ins.
This
really
was
my
primary
go-
to
workflow
for
a
number
of
years.
This
became
a
little
bit
more
complicated
as
we
went
to
the
cloud.
Like
a
lot
of
developers
now,
they're
starting
to
do
more
with
things
like
GitHub.
Now
we
have
source
files
in
the
cloud
and
GitHub
and
one
or
more
repositories.
Now
we
have
to
download
that
code.
That
code
comes
downloaded
in
a
zip
file.
Those
zip
files
then
have
to
be
extracted
into
their
folders.
Then
we
have
to
combine
the
files
together
into
a
singular
folder
that
we
want
to
deploy.
Then
we
have
to
delete
any
excessive
files
because
sometimes
you'll
get
more
downloaded
with
that
code
than
you
really
want
in
that
final
add-in.
Then
we
can
go
on
to
the
Add-In Manager
for
all
of
the
magic
we
mentioned
before.
While
this
workflow
isn't
technically
a
lot
more
complicated
than
the
one
we
had
in
the
past,
the
more
add-ins
you
manage,
that
additional
work
really
starts
to
add
up.
That's
what
I
was
noticing
when
I
was
shifting
stuff
over
into
the
cloud.
This
is
where
I
started
collaborating
with
Sage,
who
was
learning
more
about
all
the
powers
of
GitHub
and
what
it
could
do
to
maybe
combine
both
of
these
worlds
together.
Working
with
Sage,
we
came
up
with
the
best
of
all
worlds.
This
is
where
Project
JAAB
comes
in.
Project
JAAB,
we
wanted
to
fit
a
certain
set
of
requirements
in
order
to
make
this
completely
successful.
With
an
action
in
GitHub,
we
want
to
trigger
when
we
have
a
new
release.
We
wanted
the
action
to
package
up
the
repository
code
and
create
the
JMP
add-in
file.
That
package
JMP
add-in
file
needs
to
have
additional
files
from
other
repositories
if
it's
desired.
Say,
you
want
to
import
libraries
or
something
of
that
similar,
to
the
concept
of
something
like
Python.
We
want
that
JMP
Add-In
uploaded
as
an
asset
to
the
repository,
so
that
way
you
have
that
connected
traceability
with
your
releases.
You
want
to
automatically
name
the
JMP
Add-In
file.
Sometimes
including
the
version
and
sometimes
not
including
the
version.
Some
examples
of
this
are
below,
and
they
represent
something
that
with
our
infrastructure,
works
with
the
deployment
of
the
add-in,
involving
a
situation
where
people
can
get
automatic
updates.
In
those
situations,
it's
not
beneficial
to
have
the
actual
name
of
the
add-in
changing
every
time
you
have
a
version,
so
it's
better
to
have
that
removed.
But
for
general
sharing,
having
that
version
as
part
of
the
file
name
makes
things
a
lot
more
seamless.
Finally,
the
deployment.
Depending
on
your
workflow,
the
deployment
is
reall
some
of
the
best
magic
because
this
actually
integrates
into
your
specific
sphere,
and
deploys
the
add-in
into
a
folder,
structure,
or
something
like
that,
that
really
supports
your
existing
workflows.
An
example
with
what
Add-In Manager
does
is
production
releases
get
deployed
into
a
production
folder
and
test
releases
get
deployed
into
Test
folder.
You
can
keep
that
separation
still
there.
What
Sage
is
going
to
talk
about
with
her
demo
was
primarily
going
to
focus
on
these
here
because
this
is
where
the
bulk
of
the
work
gets
done,
and
this
is
the
stuff
that
is
most
ransferable
to
anyone
who
is
working
with
JMP
Add-ins.
Secondarily,
we'll
talk
a
little
bit
about
the
end,
the
deployment.
As
I
mentioned,
your deployment
is
unique
to
your
workflow.
Not
everyone
has
the
same
folder,
structures,
the
same
connectivity,
the
same
credentials,
and
all
of
those
things
that
make
deployment
potentially
transferable,
but
not
as
seamless
as
some
of
the
other
pieces
in
the
demo.
With
that,
I'd
like
to
pass
this
over
to
Sage,
who
will
start
the
demo
to
showcase
a
bit
more
of
what
we're
talking
about.
Perfect.
Thank
you,
Nate.
Let
me
go
ahead
and
steal
this
share
screen
from
you.
Let's
see
if
we
can
pick
the
right
thing
here.
The
beauty
of
multiple
screens.
All
right,
perfect.
What
you're
seeing
right
here
is
just
the
project
JAAB
repo.
As
Nate
was
describing,
I'm
going
to
give
you
an
overlay
of
what
this
one
looks
like.
Then
we're
going
to
go
through
and
we're
going
to
actually
build
an
add-in.
This
way
you
get
the
ability
to
see
with
this
in
action.
This
is
a
look
at
the
project
JMP
repo.
The
brains
of
this
project
actually
exist
in
this
AddinB
uilder.py,
and
we
will
go
through
this
at
the
end
of
the
presentation,
so
I
can
show
you
how
the
variables
do
what
they
do.
This
is
the
repo
that
you
would
use
to
do
all
of
your
magic.
I'm
going
to
show
you
how
to
use
that.
The
important
thing
here
is
this
README
file.
As
I'm
going
through
this
presentation,
if
you
for
some
reason
don't
find
this
presentation
or
are
interested
to
just
read
more,
the
README
is
a
perfectly
good
place
to
get
an
idea
of
some
of
these
things
and
what
they
actually
mean.
It's
the
know-
all-
place
location
to
find
things.
Now
I'm
going
to
go
and
I'm
going
to
actually
just
make
an
add-in.
I
think
that
that
makes
sense.
It's
a
good
place
to
start.
Here
we're
going
to
build
an
add-in
for
this
add-in
that
I
have
for
JMP
called
Daily
Affirmations.
In
this
repo,
I
have
my
daily
affirmations
JMP
table,
I
have
my
daily
affirmations
JSL,
and
I
have
my
icon
that
I
would
like
to
link
to
my
add-in.
This
is
all
going
to
get
packaged
up
into
an
add-in
for
JMP
to
use.
I'm
going
to
go
ahead
and
I'm
going
to
go
to
Actions
here.
Inside
Actions,
I'm
going
to
go
ahead
and
I'm
just
going
to
do
Configure
a
Simple
Workflow.
In
this
case,
what
GitHub
will
do
is
it
will
give
you
a
full
breakdown
of
a
completely
start-
from-
scratch
action.
In
this
case,
if
you
were
to
go
into
the
README,
you
would
see
that
there
is
a
usage
section.
What
I'm
going
to
do
is,
I'm
actually
just
going
to
come
in
here
and
paste
an
example
of
the
usage
section,
and
I'll
just
go
through
each
of
the
pieces,
this
way
you
know
what
they
all
mean.
But
in
this
case,
this
is
what
talks
to
Project
JAAB
and
says,
"To
make
your
add-in."
In
this
case,
what
we're
doing
is
we're
following
what
Nate
described,
which
is
that
when
we
do
a
release,
well,
actually,
based
off
of
a
release
published,
that's
when
this
action
will
execute.
Then
what
it
does
is
it
builds
the
add-in,
and
it
uses
the
Sage
Darling
Project
JAAB
repo
that
I
had
just
shown
you
a
second
ago
at
version
1.0.
If
you
decided
that
you
wanted
a
different
version
here,
in
this
case,
you
could
change
this
to
something
different,
such
as
if
I
had
a
version
2,
you
could
do
2
here.
You
could
also
trigger
the
main
branch
instead.
You
could
do
at
main
if
you
wanted,
which
would
be
the
main
branch
and
would
just
incorporate
any
of
my
changes
without
it
being
tied
to
a
physical
release.
In
this
case,
I'm
going
to
do
version
1.0
because
that's
the
one
that
we
released
and
is
usable.
Also
what's
important
with
actions
is
that
they
come
with
what's
called
with
statements.
In
this
case,
we've
got
a
few
different with
statements.
This
is
just
for
a
typical
add-in
build.
In
this
case,
I
have
included
a
token.
A
token
is
a
security
measure
that
GitHub
has
that
basically
says,
"You
are
who
you
are."
In
this
case,
I've
set
this
up
as
a
secret
inside
for
JMP
Discovery.
In
order
to
set
up
your
own
secret,
you
would
go
to
Settings
and
set
up
a
secret
in
there.
We
have
also
included
documentation
at
the
end
of
this
presentation.
My GitHub
has
put
together
seamlessly
to
be
able
to
describe
to
you
how
to
build
your
own
tokens.
Feel
free
to
poke
around
in
there
should
you
be
in
a
situation
where
you
have
a
private
repo
to
which
you
need
to
prove
who
you
are
in
order
to
actually
execute
any
actions.
Here
we
also
have
our
add-in
ID.
In
this
case,
I'm
calling
this
com.
JMP
Discoverys
.
s
tarlingd
aily
Affirmations.
Typically,
this
is
com.
Company,
some
name.
You're
seeing
an
example
here.
As
long
as
it's
unique,
that's
all
that
really
matters.
Then
add-in
name,
we're
calling
this
daily
affirmations
as
the
add-in
gives
you
daily
affirmations.
What
I'm
also
including
here
is
what's
called
a
jmpc
ust
text
file.
In
this
case,
I
know
that
this
file
is
going
to
be
called
jmpc
ust.txt
.
You
can
call
this
whatever
you
want
as
long
as
the
extension
at
the
end
ends
in .t
xt.
But
in
this
case,
I
know
I'm
making
a
jmpcust
.t
xt,
I'm
going
to
leave
it
that
way.
I'm
also
going
to
name
my
YAML.
In
this
case,
you
can
go
up
here
and
name
it.
You
can
literally
name
this
whatever
you
want.
I'm
going
to
call
this
JAAB.y
ml
to
be
consistent
with
the
action
itself,
but
that
name
just
matters
for
you
for
what
you
would
like
to
name
it
for
purposes.
I'm
going
to
go
ahead
and
commit
these
changes
to
my
repo,
and
I'm
going
to
say,
Added
Project
JAAB
action
to
GitHub
workflows.
Then I'm
going
to
go
ahead
and
commit
this
to
the
main
branch.
This
happens
from
time
to
time.
We
love
errors
when
we're
actually
doing
stuff,
welcome
to
code.
But
if
I
return
to
the
repository
overview
what
you'll
see
is
that
it
actually
got
added
in
anyway.
If
I
were
to
go
into .g
ithub/
workflows
and
I
were
to
do
JAAB.yml
,
you
can
see
that
it
was
actually
added.
I'm
not
quite
sure
why
that
error
comes
up
but
I've
seen
it
happen
from
time
to
time.
Definitely
something
worth
looking
into.
But
at
any
rate,
it's
actually
added
in
here.
When
I
go
make
my
jmp
cust.t
xt
and
I
go
to
run,
it
will
still
do
what
it
needs
to
do.
Essentially,
it's
just
an
error
saying
that,
"Related
to
the
main
branch."
I
must
have
done
something
in
here
to
confuse
it.
But
at
any
rate,
it's
in
this
repo,
so if
I
were
to
come
in
here,
you
can
see
that
it's
already
been
added
to
this
main
branch
anyway.
Now
I'm
going
to
go
into .g
ithub/repos,
and
I'm
going
to
go
ahead
and
add
a
new
file,
create
a
new
file.
This
is
where
I'm
going
to
make
my
jmp
cust.t
xt
file.
Again,
this
information
is
located
in
the
README
for
Project
JAAB,
where
you
can
get
an
idea
of
how
to
make these.
There's
also
some
pictures
in
there
relative
to
when
you
change
information
in
these,
what
that
actually
looks
like
upon
implementation,
should
you
not
be
quite
sure
where
things
go.
But
I'm
going
to
go
ahead
and
I'll
walk
through
this
as
well.
In
this
case,
I'm
going
to
make
for
my
caption
in
my
actual
menu
is
going
to
be
JMP
Discovery
2023.
Then
I'm
also
going
to
call
this
a
Pick
Me
Up
as
my
menu
items.
You'll
see
this
in
the
menu
in
terms
of
when
I
actually
build
this
action
or
this
add-in.
Then
I'm
actually
going
to
call
this
Daily
Affirmations.
Then
I've
also
included here
the
word
tool
tag.
Don't
edit
this
word.
This
word
is
actually
how
the
Python
keys
into
how
to
put
the
version
information
into
the
menus.
This
is
way,
people
are
aware
of
what
version
number
they're
using.
Tool
tag
is
a
pretty
important
part
of
this,
so
make
sure
you
leave
it.
Another
important
part,
the
path
to
which
your
actual
JSL
takes
place.
I
know
my
JSL
is
called
dailyaffirmations.j
sl
because
that's
what's
written
in
my
repo.
Also
here
is
a
ID
called
AdDin
IDD
oN
otT
ouCHY.
It
says
do
not
touchy
for
a
reason.
Do
not
touchy.
This
just
basically
allows
the
Add-in
Builder
to
know
where
to
put
that
Add-in
ID
information
so
it
knows
where
to
look
for
it.
But
since
you've
already
put
that
as
an
input
in
your
action,
there's
no
reason
to
double
do
it,
especially
since
code
can
find
its
way
given
the
right
syntax.
That's
what
it's
going
to
do,
it's
going
to
find
its
way
here.
Don't
touch it
.
We've
also
added
a
tip
here.
You
are
smart!
You
are
worthy!
We
will
add
that
as
information,
and
I
will
show
you
what
that
looks
like
when
you
hover
over
it.
I've
also
added
an
icon
in
here.
As
you
remember,
I've
added
an
icon
to
my
repo.
I
know
for
a
fact
I
want
to
use
that
icon
for
my
actual
add-in.
In
this
case,
I've
edited
this
to
say "p
ath,"
and
then
it
also
includes
the
ADDIN_HOME
(AdDinIDDoNotTouCHY)\ha
ppy.i
con.
This
is
a
personal
one.
This
is
because
I
have
an
image
I
want
to
use.
You
can
also
here,
instead,
do
a
built-in
one,
which
you
can
also
get
an
idea
what
the
built-in
icons
are
due
to
an
add-in
that
Justin
also
made.
I'll
add
Justin
for
another
great
add-in
that
we
can
use.
But
here
we're
going
to
do
an
icon-
type
path.
The
README
also
has
a
description
on
how
to
use
built-in
ones,
should
that
be
what
you
would
prefer.
I'm
going
to
go
ahead
and
commit
these
changes
as
well.
I'm
going
to
say
added
jmp
cust.t
xt.
I'm
going
to
commit
this
to
the
main
branch.
Now
you
can
see
that
this
has
also
been
committed
in
here.
This
jmp
cust.t
xt
has
to
be
in
the
workflows
area
for
Project
JMP
to
find
it.
Just
make
sure
that
you
are
in
this
folder
should
you
decide
that
you
want
to
search.
It
is
in
this
folder,
so
this
way,
Project
JMP
can
find
it.
Just
make
sure
this
is
where
it's
located,
or
else
it
will
not
be
able
to
find
it
and
you
will
get
an
error.
Now
I'm
going
to
go
back
to
daily-
affirmations
in my
repo.
I
think
it's
time
to
build
a
release
candidate.
What
we're
going
to
do,
I'm
going
to
go
into
Create
a
new
release,
and
I'm
going
to
choose
a
tag,
and
I'm
going
to
go
v1.O.O
RC
1.
There
is
also
version
information
inside
the
README,
should
you
need
more
context
on
how
this
actually
works.
But
essentially
what
we're
doing
here
is
we're
saying
V
for
version.
This
is
not
technically
necessary.
If
you
do
not
want
to
have
it
there,
feel
free
to
get
rid
of
it.
Just
don't
put
anything
else
at
the
beginning.
Don't
put
R,
don't
put
something
else.
It
will
end
up
causing
an
error
code.
Followed
by,
you
can
put
as
many
zeros
as
you
want
here,
as
long
as
the
digits
are
spaced
by
a
period
or
a
period
is
in
between
the
numbers,
no
spaces.
You
can
also
not
do
things
like
underscores
or
slashes.
You
will
just
want
to
make
sure
that
you
put
these
together
as
1.0.0.
You
could
also
keep
going
.0.0.0.0
to
your
heart's
content.
But
in
this
case,
we're
going
to
use
three
digits.
Another
option
is
you
could
actually
make
it
shorter.
You
could
do
1.0
if
you
wanted,
as
you
saw
in
my
Project
JAAB
repo.
But
in
this
case,
we're
going
to
do
1.0.0.
Then
we're
also
including
an
RC
here,
which
stands
for
Release
Candidate.
Project
JAAB
supports
release
candidate.
It
supports
beta
and
it
supports
alpha,
designated
by
a
dash
here.
Also
of
note
is
that
you
want
to
make
sure
that
you
include
the
one
at
the
end
here.
Don't
just
cleave
off
any
number.
You
want
to
make
sure
that
Project
JAAB
knows
that
you're
doing
a
release
candidate
and
what
number
it
is.
In
this
case,
we're
going
to
put
one
here
because
that's
the
number
that
we're
starting
with.
But
you
can
go
as
high
numbers
as
you
want
here.
I'm
going
to
go
ahead
and
say,
Create
a
new
tag.
Then
I'm
going
to
say,
Generate
release
notes,
which
will
go
through
and
pull
the
entire
commit
log
relative
to
this
before
this
release.
Then
I'm
going
to
say, P
ublish
release.
You
can
also
add
in
more
information
there
should
you
choose.
Now
what
GitHub
is
going
to
do
is
it's
going
to
take
all
those
packages
together
and
it's
going
to
run
that
action.
If
I
were
to
go
into
Actions
here,
you'll
be
able
to
see
that
this
is
queuing
up
what
GitHub
calls
as
Queued.
You
can
see
that
it's
thinking
for
a
little
bit.
You
get
this
fancy
yellow
circle.
Then
over
the
course
of
about
15
seconds,
you
now
get
your
completed
version
with
this
nice
blue
checkmark,
which
feels
really
nice.
If
this
were
to
fail,
this
is
next,
which
does
not
feel
as
nice.
In
that
case,
you
can
see
that
this
is
actually
completed.
I'm
going
to
go
into
this
version.
This
way
you
can
just
see
what
the
action
spits
out
for
information.
If
I
go
to
build-
addin
and
I
go
into
the
example
Addin
Build
with
Project
JAAB
and
I
open
this
up,
you
can
see
that
it
was
running
from
this
repo
at
this
version.
It
ran
this
Python
code,
which
we'll
go
through
in
a
little
bit.
Then
it
tells
you
information
relative
to
what
you
put
in
for
inputs.
In
my
case,
I
put
in
RC,
so
it's
a
release
candidate.
It
says
that
this
is
a
release
candidate
and
thus
it
will
be
deployed
in
testing.
It
also
tells
you
the
addin
build,
which
is
complete
for
what
the
addin
version
is.
I
included
the
tool
tag
here,
so
you
can
see,
as
Nate
had
described,
with
the
tool
tags
being
added
on.
This
is
an
example
of
that
taking
place.
Then
it'll
tell
you
that
at
the
completion
of
the
job,
it
is
uploaded
to
Git.
We're
going
to
go
and
we're
going
to
download
it.
If
I
go
over
to
Code
and
I
go
over
to
Releases,
you
can
see
that
included
here
now
in
the
Assets
section
is
this
dailyA
ffirmations
and
then
the
version
number
that
we
had
put
in
when
we
built
the
release.
Now
what
you
can
do
is
you
can
download
it.
That's
what
I'm
going
to
do.
Download
it
and
then
I'm
going
to
open
it
and
then
I'm
going
to
install
it.
Now
that
I've
installed
it
because
it
happened
super
quickly,
there
is
a
JMP
Discovery
2023
here.
This
was
not
here
before.
Now
if
I
were
to
click
this
and
you
can
see
A
Pick
Me
Up!
Which
is
what
we
had
written
in
the
jmpcust.t
xt
file,
and
then
Daily
Affirmations,
and
then
the
version,
V1.0.0
RC
1
is
linked
to
this
location.
Then
you
can
also
see
the
caption
here.
You
are
smart!
You
are
worthy!
Came
up
from
the
jmpcust.t
xt
file.
This
is
an
example
of
this
being
pulled
through.
Now
what
I'm
going
to
do
is
I'm
actually
going
to
open
the
files.
This
way
I
can
demonstrate
what's
actually
inside
of
these.
In
this
case,
the
project
JAAB
went
through
and
built
in
the
add-in.d
ef
file.
It
went
in
and
built
in
the
addin.j
mpcust
file.
It
also
included
those
three
files
that
were
located
in
the
repo
in
order
for
us
to
be
able
to
build
the
add-in.
These
are
just
the
generic
things
that
get
built-
in
when
you
don't
have
anything
added
like
metafiles
or
anything
like
that.
For
our
next
version,
I'm
going
to
go
in
and
I'm
going
to
show
you
how
to
add
in
the
metafiles.
Should
you
want
to
do
metafiles
you
don't
necessarily
have
to
for
production
releases,
but
I'm
going
to
link
them
both
for
an
effort
to
be
continuous.
We
will
do
our
production
release
and
what
that
looks
like.
Then
we
will
also
add
in
the
meta
file
information.
This
way
we're
consistent
with
showing
those
two
steps,
but
you
don't
necessarily
have
to
do
them
in
tandem.
These
are
our
files
that
are
located
here.
What
I'm
going
to
do
is,
now
is
the
time
to
go
through
and
do
a
production
release.
I'm
going
to
go
ahead
and
I'm
going
to
go
back
over
to
Code.
I
know
for
a
fact
there's
nothing
about
this
code
that
I
want
to
change.
Oh,
I
forgot,
I
didn't
even
run
this.
You
should
see
what
it
looks
like
when
you
run
this.
If
I
click
this,
you
get
a
key
little
window
that
tells
you
some
positive
affirmation.
In
this
case,
"Negative
people
need
drama
like
it's
oxygen.
Stay
positive
and
analyze
this
data!
This
is
what
the
add-in
actually
does
when
you
execute
it.
But
now
I
know
that
when
I
execute
this,
everything's
working
flawlessly.
I
know
for
a
fact
that
now
it's
ready
for
production.
That's
what
we're
going
to
do
is
we're
going
to
launch
it
into
production.
I'm
going
to
go
back
into
GitHub
Workflows.
I'm
going
to
go
into
the
.y
ml.
I'm
going
to
edit
this.
I'm
going
to
go
ahead
and
I'm
going
to
add
a
little
bit
more
notes
to
the
bottom
of
this.
Which
is
that
I
would
like
to
add
in
my
making
of
the
meta
file.
We're
going
to
make
our
metafile,
which
is
what's
set
as
true
here.
This
is
typically
set
to
false,
which
is
why
I
didn't
have
to
add
this
in
as
a
input
before.
But
in
this
case,
I
want
to
make
a
metafile.
Again,
this
isn't
necessarily
linked
to
publishing
add-ins
for
production
release,
but
in
this
case,
I
want
to
show
what
that
looks
like
when
it's
actually
inside
of
the
add-in.
The
pub
names,
this
is
the
actual
name
of
the
published
list
add-ins.
In
this
case,
I'm
showing
those
pubaddins.j
sl.
This
is
what
gets
edited
when
you
actually
deploy.
In
this
case,
I'm
just
showing
as
pub
add-ins.
Typically,
it's
called
publish
addins,
but it is
actually
default
to
publish
addins,
but
in
this
case,
I'm
overriding
it
just
to
show
an
example
so when
I
show
you
the
meta
file,
you
can
see
what's
written.
This
is
the
final
pub
paths.
This
is
where
the
actual
add-in
is
being
published.
Again,
this
gets
written
into
the
meta
file
information.
This
is
how
you
would
put
it
in
for
syntax
relative
to
putting
that
into
the
actual
add-in.
I'm
also
going
to
exclude
the
tag
suffix
here
for
production
release
and
to
show
that
when
you
exclude
the
tag
suffix,
it
no
longer
included
into
that
file
when
it
gets
added
as
an
asset.
That's
that.
I'm
going
to
go
ahead
and
commit
these
changes.
I'm
going
to
say
added
some
inputs
for
metafile
and
tag
suffix
removal.
I'm
going
to
go
ahead
and
commit
these
changes.
Then
I'm
going
to
go
back
to
Code.
We're
going
to
go
to
Releases,
and
I'm
now
going
to
draft
a
new
release.
In
this
case,
I'm
going
to
do
version
1.0.0.
I'm
going
to
go
ahead
and
again
generate
release
notes.
Then
I'm
going
to
go
ahead
and
say
Publish.
In
this
case,
I
cleaved
off
the
-RC
1
because
I
know
this
is
a
production
release.
I
know
I'm
ready
to
put
this
into
production
mode
by
cleaving
off
any
release
candidate
alpha
or
beta
that
makes
it
this
way.
It
sees
it
as
a
production
release.
In
this
case,
I'm
doing
the
version
that's
actually
a
production
release
and
not
some
release
candidate
related
to
it,
which
is
why
it's
the
same
code.
Then
if
I
go
over
to
Actions
again,
you
can
see
this
is
already
completed
in
a
cool
15
seconds.
Again,
when
I
go
back
into
this
build-
addin
information,
the
difference
is
that
you're
going
to
see
is
that
the
custom
metadata
has
been
written
to
the
file
location,
so
you
know
that
that
got
written
in
there.
You
also
know
that
this
release
is
a
production
release
and
will
be
deployed
in
production.
It'll
show
you
those
locations
as
well.
Now
if
I
go
back
and
I
go
back
to
Releases
and
I
go
ahead
and
I
click
this,
you
can
see
that
this
no
longer
has
the
tool
tag
at
the
end
of
it,
which
the
tag
suffix
takes
away.
If
I
go
ahead
and
click
this,
now
it's
ready
for
download.
I
go
ahead
and
open
it,
I
install
it.
Now
you
can
see
that
the
JMP
Discovery
2023
stayed
the
same.
The
Pick
Me
Up!
has
also
stayed
the
same,
but
now
you
can
see
that
it's
Daily A
ffirmations
version
1.0.0
and
no
longer
release
candidate
one,
where
the
add-
in
itself
has
not
changed
at
all.
It
still
executes
the
same
way.
It's
just
changed
the
version
information.
This
way
you're
aware
of
what
version
that person is on
and
as
they
are
as
well.
Then
you
can
get
some
fancy
quote
with
the
daily
affirmations.
That's
that.
That's
an
example of
building
an
add-in
with
Project
JAAB
related
to
this
type
of
action,
related
to
this
type
of
repo
as
well.
What
I'm
going
to
do
now
is
I'm
actually
just
going
to
jump
into
the
repo
itself
and
give
an
idea
behind
the
brains
of
what
the
Add-In
Builder
actually
is,
in
order
to
show
some
of
the
information
related
to
what
drives
this
action.
The
AddinB
uilder.p
y
is
what the most
of
the
brains
of
this
project
is.
You
can
see
that
there's
Python
in
here
as
well.
You're
welcome
to
take
a
gander
at
this
at
your
leisure
if
you
find
reading
code
interesting.
There's
a
bunch
of
different
support
functions
here,
the
real
brains
of
how
this
actually
works
is
this
json_out
function,
which
actually
connects
to
the
GitHub
API
in
order
to
get
the
information
for
your
action
and
for
your
repo.
This
also
has
an
example,
usually
just
the
json_out
function,
so
you
can
see
what
the
actual
output
is
and
what
you'd
be
targeting.
Then
at
the
end,
the
very,
very
end,
which
I'm
going
to
scroll
super
quick
because
there's
a
lot
of
code
here,
at
the
very
end,
there
is
this
environmental
variables,
which
is
how
you
actually
get
passed
in
from
GitHub.
When
you
put
in
your
inputs
like
we
had
just
done
with
the
action
in
the
Width
section,
this
gets
pulled
in
from
that
action
in
that
environment
to
then
get
passed
into
this
Python
script.
This
is
how
these
variables
are
connected.
You
can
go
ahead
and
take
a
look
at
this
full
flow
and
see
how
all
that
translates
to
build
the
add-in.
But
that's
the
brains
of
how
this
actually
works
and
how
the
variables
are
passed
in
between
the
two.
Last
but
certainly
not
least
is
that
this
is
an
ever
growing
code
base.
It
is
open
to
you.
The
repo
is
available
for
you
to
take
a
gander at,
for
you
to
use
at
your
leisure.
But
also
we're
looking
for
feedback
and
anything
else
that
you
feel
would
be
necessary
for
growth
here.
If
that's
the
case
and
you
have
something
you
want
to
say,
you
can
either
shoot
us
a
message,
either
Nate
or
I
and
our
contact
information
is at
the
end
of
the
presentation.
Or
you
can
also
go
into
the
Issue
section
here
in
GitHub,
of
which
you
can
actually
say
N
ew
issue,
and
you're
welcome
to
put
any
information
that
you
think
would
be
great
for
bug
fixes,
or
anything
else
that
would
be
helpful
for
adding
in
more
information
for
the
actual
creating
of
this
to
make
this
more
intricate
and
seamless.
That's
that.
The
last
step
of
this
is
obviously
deployment,
which
is
not
included
in
Project
JMP
in
this
case,
and
that's because
we
have
a
very
specific
IDEXX
infrastructure
for
how
that
works.
But
I'm
going
to
let
Nate
talk
a
little
bit
about
that.
We
would
actually
love
to
hear
more
information
from
anybody
else
about
deployment
or
talking
further
into
it.
I
will
let
Nate
cover
the
deployment
section
for
how
we
do
it
here
at
IDEXX.
Sounds
great,
Sage.
Thank
you
very
much
as
I
pull
this
up.
As
she
mentioned,
the
last
step
in
the
process
is
deployment,
and
it
is
very
unique
to
individual
organizations.
But
a
little
bit
about
how
we
do
it
is
we
have
the
step
where
we
pull
all
of
our
stuff
in
GitHub
the
way
Sage
had
described,
utilizing
some
of
the
additional
inputs
she
talked
about
for
that
release,
like
the
creation
of
the
metadata
file,
some
of
the
tool
tag
stuff.
That
all
fits
also
into
what
then
goes
into
a
runner
that
runs
on
a
local
computer
here
at
IDEXX
in
order
to
seamlessly
connect
into
our
network
infrastructure.
There's
a
link
at
the
bottom
as
well
as
the
end
of
the
presentation
talking
about
self
hosted
runners.
Everything
Sage
talked
about
was
hosted
directly
on
GitHub
runners
as
opposed
to
something
done
locally.
Also
on
our
local
computer
here
at
IDEXX,
we
have
a
Python
that
gathers
inputs
and
retrieves
the
JMP
add-in,
all
very
similar
to
what
Sage
had
just
talked
about.
But
the
tail
end
of
that
actually
takes
that
add-
in
and
it
deploys
the
add-in
to
a
folder
structure,
that
can
then
be
synced
to
whatever
network
capability
we
need
in
our
system.
For
instance,
production
JMP
Add-Ins
go
into
the
production
folder,
test
goes
into
a
test
folder,
etc.
In
addition,
it
also
updates
what
would
be
called
the
published
addin
info
file.
I
think
pub
addins
is
what
Sage
called
it
in
her
example.
Having
that
information
in
the
metafile,
correlates
to
using
the
published
add-in
file
if
you
want
to
do
something
like
automatic
updates,
because
then
it
syncs
the
information
and
tells
other
functions
where
to
look
in
order
to
execute
those
pieces.
Again,
we
would
love
to
discuss
this
more
with
people
to
see
how
they
may
want
to
implement
it,
because
this
is
very
unique,
but
I
think
it
offers
them
really
unique
options
for
people
to
bring
into
their
own
company
infrastructures.
That
takes
care
of
the
bulk
of
everything
we
wanted
to
talk
about
today.
I
think
at
the
end
of
the
presentation
here,
we
discussedâ¦
Here's
a
very
simple
list
of
links.
This
is
also
available
as
a
standalone
file
with
the
uploaded
presentation.
If
you
would
like
to
get
in
touch
with
us
other
than
through
the
Issues
section
of
the
Action,
you
can
contact
us
through
email,
GitHub,
LinkedIn.
We're
also
both
on
the
JMP
Community.
Here
is
my
information
and
here
is
Sage's
information.
Please
feel
free
to
reach
out.
I
believe
also
you'll
be
able
to
have
a
comment
thread
running
on
the
on-
demand
website
as
well.
Lots
of
ways
to
get
in
touch
and
have
a
really
good
discussion
about
everything
we
want
to
talk
about.
With
that,
I
think
we
are
done
with
the
presentation.
We
look
forward
to
everything
you
have
to
say.
I
guess,
happy
JAABing.
Have
fun
JAABing.
