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.