One CLI to Rule Them All

JFrog products all have awesome REST APIs, but sometimes using curl is just painful.  JFrog has the CLI to manage artifacts in Artifactory and Bintray.  The CLI also is useful for a variety of administrative tasks related to JFrog Mission Control, JFrog Bintray and JFrog Xray.  Recently, the JFrog CLI has received some major new features related to artifact management that make it a very powerful tool for generic package management and build tooling, and this webinar will discuss what these powerful capabilities can do for DevOps processes.

Webinar Transcript

Hello everybody. And welcome to another JFrog webinar. And today we’re going to talk about JFrog CLI. Today with me, my name is Baruch. I’m developer advocate with JFrog and with me today, Mark Galpin solution architect that will help me to do a demo. Also as a last minute pleasant surprise, we have with us [inaudible 00:00:40], who is the lead developer of a JFrog infrastructure ecosystem team, which includes the JFrog CLI. You’ll have the great opportunity to ask [inaudible 00:00:52] questions that probably only he can answer. Regarding the questions, feel free to ask any question in the Q and A window, and we’ll answer as much as possible towards the end of the webinar. And I guess again [inaudible 00:01:14] the perfect person to answer any questions that you may have. Also chat window is available so if you have additional comments or something that you want to say to us, feel free to use chat as well.

This is agenda for today. We’ll talk about what is Jfrog CLI, and why we think you should use it. We’ll talk about, I would say, the most common usage of JFrog CLI to perform credit operations, [inaudible 00:01:47] for create, read, update, and delete operations. And we’re also going to talk about some new and awesome additions to JFrog CLI that will allow you to create, build information, build metadata out of CLI itself. And of course, I will talk about how JFrog CLI works with all the JFrog products, not only [inaudible 00:02:12] of course, right? First of all, why you need something like that? Why would you use JFrog products of factory Mission Control x-ray not through the UI? What’s wrong with the UI and the answer is using a tool like [inaudible 00:02:29] interface allows you to create automation and automation is the key for faster release cycles.

And today, as you all know, every company is a software company and being able to deliver your software faster to the market than your competitors gives you, of course, the competitive advantage that we all look for. Automation is extremely important. And regarding that, I would like to ask you something. Let’s run a poll right here. It’s a multiple choice. Feel free to select more than one option. And the question would be, you probably know that automation is important and you probably use something that automates your work with JFrog tools: JFrog Artifactory, JFrog Bintray, of course. My question would be what do you use? REST API, or maybe user plugins or combination of those, or maybe you are already familiar with JFrog CLI, use it and here to learn what’s new and what more we can do. Not answering any of those basically means you don’t automate it all. Well, let’s give it a little bit more time.

Okay. There are only a couple of results, unfortunately. I’m not sure what it’s attributed to. Maybe some of you didn’t see the poll, or maybe some of you don’t use the and automate around JFrog tools, but from the results that we got, what I can see is that most of you use REST API. And that makes perfect sense, of course, because REST API is the canonical way to automate around tools. Not only JFrog, not only Artifactory, of course, any tool when we want to automate around it, we write scripts that trigger REST API, and that’s of course, a valid option. JFrog CLI builds on top of REST API and I’m going to talk about it just a little bit and makes it more comfortable and more safe to use.

And of course we have multiple products that play together and provide a unified interface towards the user. The user interface looks alike, and that means that the common line interface looks alike as well. And JFrog CLI supports all four products. In today’s webinar, we’ll concentrate more on Artifactory and Bintray, but we will also mention how JFrog CLI works with all of them, works with JFrog Mission Control and JFrog X-ray as well. What is JFrog CLI? How it’s implemented and what it does. In an essence, it’s a [inaudible 00:05:53] upper on top of REST API. It’s written in [inaudible 00:05:57] so it means that you have native builds for all the popular platforms. You can download it and then run comments instead of customizing curl to work with the REST API. It’s a wrapper that gives you, of course, the convenience or writing well known commands.

And it also safer than using REST API, because if you get some comment wrong, it just won’t work instead of sending the request anyhow and getting better results on this stuff. It’s both convenience and safety. And as you will see, the demo is much more comfortable to work with than to work with directly with REST API. That also means that we have… Every time our API evolves in Artifactory and Bintray in any of the products, the CLI evolves with them. It might take a couple of days for CLI to catch up, but you can still of course use the REST API right away as you used to. It doesn’t replace the REST API, it doesn’t obsolete or deprecate the REST API. It’s just a layer of convenience on top of it. You more than welcome to use it, but of course you use the REST API directly as well.

And it allows you to do some awesome things like creating a dependency management for tools without dependency management. I’m going to talk a little bit about that or running [inaudible 00:07:37] language commands and scripting grounded. For example, AQL based cleanups that we’re going to talk a little bit about as well or the third example is creating what we call the build info and that’s creating, gathering, and uploading and attaching to artifacts, metadata about the build that created it. And just to elaborate on those three, the most interesting and attractive use cases for a JFrog CLI. Dependency resolution for tools without dependency management, since you can script the download of artifacts from Artifactory, you can download all the dependencies that you need before the build runs to a location that is expected by this build. And we’ll show it in a demo.

Think about the manuscript that expects the dependencies to be at the lib folder. The way they will get to this lib folder is by using JFrog CLI, downloading [inaudible 00:08:43] files before the build and putting them there. And then your build runs, it uses the dependencies and provides some output. And eventually you can, after the build, you can gather the artifacts that were created and upload them to Artifactory with the build materials that I’m going to speak a little bit more. Another example, as I mentioned is AQL comments. For example, AQL cleanup, a lot of our customers are interested in cleanup of their Artifactory. Instances from files, which are big or not in use anymore, usually combination of both. Again, with the CLI you can script around this process so you can find artifact which are big, used and also disposable, maybe third party [inaudible 00:09:40], maybe old snapshots or something like that.

And then you can find them, delete them in one go by using one command from JFrog CLI. And of course you can build safety check around it, for example, dry run mode that only shows you which artifacts are found and can they be deleted or not, or just running search without actually running the delete so you won’t delete something that you didn’t intend to. And of course the [inaudible 00:10:09] feature from Artifactory here is another safety net that actually gives you the ability to restore what you deleted. And third interesting scenario that I selected to highlight is the building for creation. The build info, generally the build abstractions that we have in Artifactory, and I’m sure you’re all familiar with it. It allows you operating on a higher level of abstraction related to your artifacts. Instead of talking about files, I need to promote this file.

I need to delete this file. I need to release this file. We are going to talk about builds and builds are actually much more important than artifacts because builds are your products. What the CI server outputs is your product, the subset of files with the dependencies that’s exactly what you’ll eventually ship. JFrog CLI with Artifactory supports the build notion. You can use builds to operate with files. You can say download all the files of the build or promote all files of the build, but also it allows you to create this abstraction on top of set of files and method that comes with it. You can ask JFrog CLI to take a bunch of files and group them as a build and add all the metadata about the build, how it was built, when it was built, by whom, all this information that you have when you actually run the build on the common line and then actually publish it together to Artifactory.

In the past, and currently, the most common way to create a building for is use a build to plugin like a [inaudible 00:12:07] plugin or a [inaudible 00:12:09] plugin or an MS build plugin to create this build info or integration with CI servers. Jenkins [inaudible 00:12:18] CT Bumble, they all know how to create this build info, but you also have this ability to create custom build info objects from your build, even for tools which are not supported. Getting back to our make example, when you run this make file, you have all the information about the build: which artifacts were produced, which dependencies were used, what was the environment variables in the time of the run, who run the build, how long it took. You can take all this information tie it together in the build info object, and actually promote all of it together with the artifacts to Artifactory, applaud all of it with artifacts, right?

Those three examples are just to show you how powerful JFrog CLI might be and how powerful your automation might be so it allows you release faster, of course, and being in front of the competition in this regard, right? And there are tons of additional features, for example, very important feature for… I wish more tools would use this approach is storing the credentials separately from comments. You preconfigure your JFrog CLI instance with the URL of your factory, if that’s Artifactory, or just, if it’s been [inaudible 00:13:44], we don’t need the URL, of course. And then you provide credentials, username, and password, and they are securely stored on your file system. And then you can run comments that won’t include this sensitive information as username and password. And that allows you to write scripts, which can be then shared through version control or in any other way without compromising username and passwords.

And that’s very, very important as well. Another feature and a couple features of JFrog CLI come from, of course, our experience with Artifactory and Bintray. We know the importance of check some based operations with large binary files and we incorporated in JFrog CLI as well. The uploads of CLI are checksum-aware which means that we first send the checksum to Artifactory to know whether those files exist or not, and we’ll do actual upload over the network only if those files are new. If those files already exist, instead, we will create those references that we know how to create in Artifactory and Bintray. Of course, increasing the speed of your builds dramatically. If your build didn’t produce any new files in terms of the content, the upload will be immediate because we will just let Artifactory know here are additional new names for the same files.

Same with downloads. Downloads are checksum-aware. If you already have those files downloaded, they won’t be downloaded again. And that’s of course speeds up the resolution a great deal. Also, parallel uploads and downloads, you can specify how many threads you want CLI to perform uploads and downloads. And that’s of course, a big deal as well. And also very nice feature that I already mentioned, the dry run mode. Dry run mode allows you to run the command and see the errors that we can anticipate before the command already starts. Right? We warn you, for example, if you try to upload snapshots into a [inaudible 00:15:55] repository, or if your user don’t have the permissions needed to perform this operation, or this kind of errors.

More on the technical side of things, the installation of Jfrog CLI is also straight forward. Especially if you’re on Mac, you can just run brew install Jfrog CLI go, and you will have the CLI installed. And otherwise you can go to bintray.com/JFrog/JFrogCLIgo and you’ll have a bunch instructions for any other operating system. It’s generally, usually will be a core command that will download and configure your show environment to use the JFrog CLI out of the box.

The usage, as I mentioned, is unified across all the JFrog products. JFrog will be the command. And then you have which tool you want to use the CLI for. RT, for Artifactory, bt for Bintray, mc for Mission Control and xr for X-ray. And then the command you want to do can be upload, download, or stuff like in Bintray maybe create [inaudible 00:17:15] in Mission Control at instance, or at license. And then the common options that make sense for this particular command. Again, very simple, very intuitive and unified across all the JFrog tools.

Let’s start art with a couple of examples of Artifactory. All them create, [inaudible 00:17:42], delete, create, read, update, and delete operations, all the code operations except parameters, which specify which files you want to operate. And you can then specify the files by, for example, spec, we’re going to talk about spec in a second. By build, you can set, download all the files from a certain build or by regular expression. Download all the files starts with Z, and also it supports properties filtering. And that’s another very important concept that you probably know from Artifactory resolution and REST API, the ability to say download all the artifacts from a certain repository or a certain path, or maybe a certain build, but only if some property set some value if the QA property set to pass or you need coverage set to 90 or whatever makes sense for you.

And you, of course, can filter that as well. I mentioned spec, and you probably wonder what this spec is. Spec is a DSL domain specific language for describing files. And again, here, it’s extremely flexible. You can specify pattern of where those files are. All the files in certain directory, under a certain rep, all the files that… And with [inaudible 00:19:18], I want all the jars from this directory or repository, of course, this stuff, or all the files, except the files with sources qualifier. I want all the files, but not the sources, et cetera, et cetera. That’s the pattern. You can also use Artifactory query language query inside the spec so you can ask for, and here, of course, the sky is the limit of how you can write the query. Give me all the files from this repository from a certain build, give me the latest build, but only if it has property QA set through, and the files never been downloaded and bigger than 100 megabyte. The query is the same.

Doesn’t make any sense, but of course, it just shows you how flexible those queries are. You can use Artifactory query language inside the spec as well. And two additional features that people find useful is the ability to set a recursive mode. Let’s say, I want all the files under a certain directory. Do I want to go into sub directories as well, or just give me the top player and the ability to flatten the files that I found. Give me all the files from these three, but make them a flat list when you download or when you upload them to and from Artifactory. Spec is a very powerful construct. And we use this DSL spec not only in JFrog CLI. If you use our latest Jenkins integration with Jenkins two that’s also a DSL that uses this spec to describe files that we want to work with.

And that’s, again, very powerful because that means that you can reuse the specs. You can describe them once and then use them both for the CLI and for your CI seven. Additional commands on top of [inaudible 00:21:28] are collecting publishing build info. As I mentioned, you have your files all ready to upload, but you also build this building for object, who made the build, how to end, the environment variables, the dependencies, et cetera. And then you can publish this building for [inaudible 00:21:43] Artifactory together with the files and the ability to just run using AQA. It’s not a crowd operation, nothing happens to the files, but you can send queries to Artifactory and get results from Artifactory using JFrog CLI and that’s actually a very nice feature comparing to the rather complicated query or command that to construct if you wanted to run AQL query from REST API, for example.

Right? As I mentioned, JFrog CLI is a convenience wrapper on top of REST API. That’s in very high picture what CLI can do for Artifactory and, of course, Mark here is getting ready with his demo to show you what I just mentioned in a life example. CLI for Bintray, again, the CRUD operations are similar to Artifactory. You can create, read the update and delete files on Bintray using the same concepts of regular expressions and patterns. That’s the same. Operations which are unique to Bintray are operations on Bintray entities so you can create or read, update and delete repositories, packages, versions, products, and whatever comes with that. And also operations, which are unique to Bintray stuff like working with download keys, entitlements, access control, et cetera. You can create entitlements, you can create download keys, you can create entitlements on them, give them access, et cetera, et cetera, all from the CLI, again, allowing you much more automation capabilities than before. With that, I would like to give it to Mark for the demo. And then we’ll get back to talk a little bit about Mission Control, X-ray and how CLI works with them. Mark…

Mark, [inaudible 00:24:13]. Oh, here we go. Welcome.

Okay. Thank you very much Baruch. First of all, we’re going to run through a fairly simple little script, but as is our practice for these webinars, all of the commands that I’m going to use are going to be listed here in JFrog training demo scripts in the CLI webinar folder. If you want to do something similar yourself, you can use that as a starting point. First off, we’re going to do just a quick look at the Artifactory commands, and you can see that there are commands for config, upload, download, moving, copying, leading, searching, and various commands related to build. And of course there’s always dash, dash, help on any sub command or sub command, which will give you a good idea for helping. For example, you could do JFrog RTC dash, dash, help and it will now give me the specific options for the config command.

And we’ll start out with a config command, and it’s going to tell me what URL I am already pointed at, and I can just hit enter to keep it. It’s going to ask me for an API key. If instead I want to use username and password, I just hit enter. Then it will tell me what user I’m logged in as, and then I have to provide a password and then it will go out, confirm that it’s got connectivity to Artifactory, encrypt everything on disk so that your plane text password is not stored anywhere. And you can move on.

Now, the next step is the download command here. This is a very set download command. I’m going JFrog RTDL, which is download. Then the first thing is the location on Artifactory and I’m grabbing the entirety of the folder and the [inaudible 00:26:24] local repository or JFrog example [inaudible 00:26:29] API, one dot one. And then I’m adding on to the end of this, a build name, CLI example, and a build number. And the point of having a build name and build number is that the CLI will now store information about this build locally until I decide to publish the build info.

All of my CLI operations, if I put these arguments at the end of them, then it knows to add them to that build info, which will then be prepared for me to publish whenever I’m done with my activity. And we’ll see how that works as we move on. But for now, you’ll see that I tag this to all of my commands. And it goes out and you can see that it converts my folder name to an AQL, which is how the CLI always works. It converts whatever you give it into an AQL, and it downloads those artifacts. And you can see Baruch mentioned the multi-threading approach, and you can see that we had two simultaneous threads downloading these two artifacts.

Now that’s cool, but before I move on, I’d like to download with a slightly more complex expression, but really I want to use the spec feature because as Baruch indicated, one of the great things that the CLI now enables, and this is relatively new with the CLI one five, is the ability that you can save a spec file and constantly reuse it both from the command line. A developer, if a developer wants to do a build, they can run the CLI with the spec file and download everything to prepare their environment to do a build at their desk. And you can use those same specs in CI. In this case, I’m going to use this spec, and this is just a simple ant pattern based spec, and I’m going to target the local place. And the only thing that’s addition into the add spec, I’m also saying that I want every file I download from my [inaudible 00:28:53] example to be from build number 12 of the [inaudible 00:28:56] example CI server build, and I’m going to pull everything recursively.

I don’t want to flatten my files. I want to maintain the standard pathing. I’m not using [inaudible 00:29:08]. And for those of you who are familiar with our Jenkins pipeline DSL, this pattern should look very familiar to you because this is exactly the same patterns that we use in the Jenkins pipeline DSL, so that you can reuse them in Jenkins and in the CLI. With that, we will execute it and you can see there’s a very simple command. I run the JFrog RTDL. Now I provide a spec, the spec [inaudible 00:29:40] JSON, and again, I’m going to provide the build name and the build number.

Now, one thing I want to note here is you get this file already exists locally. One of the things that downloaded was the API 11.jar. And I had downloaded that previously in the last command. I also downloaded the API-1.1.jar And so rather than download it again, as Baruch said, the CLI is checked somewhere. It realized that, hey, the file is already here. I don’t need to download it again. And this goes for a much faster approach, and it also allows you to use the CLI to do incremental updates of directories based on what’s inside Artifactory.

The next thing is, I’m getting ready for my build, and I want to collect my environment variables, that’s build, collect environment, that BCE, with that same CLI example and the build number that I’m on and Baruch talked a lot about make, which is a very powerful thing to combine with JFrog CLI. I’m going to a much simpler build than run a make file. I’m just going to [inaudible 00:31:05] these into a tarball. And then the next is to upload my tarball out to the generic local repository in Artifactory under name CLI example, sample CLI, and again, with the same build name and build number.

And you can see that because I provided the build name and build number, it also is going to sign the artifact with the build name, build number and timestamp, which is required as part of a build upload process. And now I’m just going to publish the build.

And it tells me to go browse it under the build info. Let’s go do that. Here you can see build number five, which is the build I built. You can see that the agent is the CLI number is one five. You can see who logged into Artifactory, when it happened and if I go into published modules, I can see that my published module was this tar file. And here are all of the dependencies of this file, which in this case, of course, are the things that I packaged inside of it. And if I jump out to this file, just like I would expect it has the build name, the build number and the build timestamp. And it has the various information of the build in it.

And if I wish, I can also see the environment variables and just like any other build, I can diff it against the previous build, build four. I can see that the tarball changed a little bit, probably because the timestamp and naming changed and the other packages inside of it did not. And none of the environment variables changed except for the environment variable where I was storing the build number.

Very basic stuff that you can collect with build info, but it’s a very new capability that you can now do that with the CLI so you don’t need to have any special tool doing your build. You can collect it all inside any standard scripting tool. Now, what I want to do next is delete an artifact and actually delete a whole bunch of artifacts. I want to clean up what I just did. Rather than do it with a pattern search, I want to do it with an AQL. And so you can see this is a basic AQL with an item [inaudible 00:34:23] find. I kept it very simple. I’m just deleting everything with the build name, CLI example from the repository generic, local, but you can make this AQL as complex as you wish. Anything in the items dot find domain, you can add to this AQL when you run it.

We’re just going to run this command and it’s going to pop up and it’s going to say, hey, I’ve got artifacts from build four and build five. Are you sure you want to delete them? And I’m going to say yes. And they are now deleted. This is pretty amazing. Previously some of you listening may be aware that we had a Groovy script that had this same behavior of deleting artifacts based on an AQL. And now we can do this with the CLI. You don’t have to worry about having the right version know Groovy or any Groovy dependencies or anything like that. Just download the CLI, build out this AQL spec and use the CLI to perform this activity. And so that Groovy script has basically been deprecated based on this new CLI option.

That’s the basics. Of course, there’s a lot more you can do with the CLI, but I also wanted to show in Artifactory, but I also wanted to show a little bit about the other tools. I want to start with Bintray. We have this wonderful package, let’s get it ready to distribute to the world. The first thing I need to do is I need to create a package in Bintray so I’m going to go out to Bintray. I’ve got this generic repository and it currently has no packages in it. Now I’m going to create a package. First of all, let’s actually just look quickly at all of the entry commands I can do config, which I’ve already done. I can upload, download, do various alterations on packages, on versions, on entitlements, on keys.

And if we do a JFrog PC–help, JFrog BT, PC–help, you can see that I have various flags I can set on a package when I create it. I’m just going to keep it very simple. I’m just going to create a package and give it a description. And I’m going to call this package CLI example and give it a description accordingly. And it’s going to give me back the full JSUN for this package. And now I can see that I have a package in Bintray and now I want to upload my tarball to this repository.

I just provide the name of the tarball. And then I provide the organization name in Bintray, the repository name, generic, the package name, CLI example, the version number I want to upload to and I’m also going to set a flag published equals true so that it’s published on Bintray as soon as I upload it. And if I don’t include this flag, then it’s going to sit on Bintray for a while for me to decide when I’m ready to upload it. This allows me to upload a number of files in order, and then publish it out once I’m ready.

And you can see that it verifies that the repository exists. It verifies that the package exists. It checked if the version number existed, since it didn’t, it created it, and then it uploaded the file. And if we go up to Bintray here, you can see now here’s the version number. I’m going to jump into here. I can see version five. I can go to its files and I can show it in the download list. And now that will now be the default download package for this version. And now if I want to download this package, I can just click here and it will download it very fast from the CDN. And again, there’s many more things you can do with Bintray with the CLI, but I also wanted to cover the last two products. First of all, JFrog Mission Control… JFrog Mission Control really only allows you to manage instances.

And this is designed to be part of the scripting that you do when you are creating new Artifactories. The idea of Mission Control is it allows you to manage Artifactories in a worldwide architecture. And of course, this means that you’ve probably got automated deployment mechanisms and this command line can be part of that automated deployment. If you do JFrog RTI, [inaudible 00:40:25] you can see that it allows you to add an instance, register that instance with Mission Control. It allows you to de-register an instance for Mission Control. It also allows you to attach and detach licenses if you’re using our license bucket feature for very large enterprises.

And the last capability we have is with X-ray and the CLI for X-ray is still just starting out. And what it allows you to do is offline updates. X-ray is a tool that is used for getting inside into binaries, what’s inside them and what important, critical information do you have about the binaries inside the component graph? And the one of the key use cases of X-ray is security vulnerabilities and Jfrog provides a security vulnerability database to go with X-ray. Now, the problem with security vulnerability databases is that you have to constantly update them. But we also know that we have many customers that need to operate in an environment that’s not hooked into the internet. And so the solution to this is to use our database sync with the CLI and what’s going to happen here is that it’s going to allow me to automatically generate the download command.

And it’s going to give me, in this command, JFrog X-ray offline update. It’s going to specify a license ID and then the numbers that we want to run, and then it’s going to go and start downloading them. And this can take a while. It’s been a while since I’ve updated this server, as you can see, a couple weeks, so this could take a while to download them all. We’ll just let that run. And that concludes the demonstration portion of our activity. And I’m now going to hand it over for questions.

Okay. Thank you very much, Mark. And just to get back for a couple of more slides here, you successfully hijacked the slides that I had down the road about CLI for Mission Control and X-ray, and just to summarize and probably repeated a bit of what you said. For Mission Control, those are early days, we are adding more and more features to support more and more operations. At the moment, you can perform operations on Artifactory or multiple Artifactory instances at once using JFrog CLI and that’s adding, removing and converting the license of the instances and CLI for X-ray. The first operation and of course the longer list of what the CLI will do is updating the database as you already show. Now you did the very brief production to X-ray.

Thank you and for the participants that want to learn more about X-ray and of course there is a lot to learn, we invite you to the X-ray webinar that we’re going to host towards the end of this month. What it is? Two days, four days, couple of days from now. JFrog.com/webinar will give you the list of all the upcoming webinars, including, of course, the X-ray one. And now I would like you to write us what else would you like to see in JFrog CLI and especially in using the fact that [inaudible 00:44:47] is here with us, that will be very beneficial. Use the chat window and give us what is important for you [inaudible 00:44:57].

And while you are doing so, let me just briefly a little bit of where you can meet us and learn more about all stuff and all stuff JFrog. As I already mentioned, JFrog.Com/webinar will take you to a list of upcoming webinars. It includes the extra webinar that I mentioned, Bintray webinar that is coming soon to learn more about JFrog Bintray. And of course our Tuesdays with JFrog series, every Tuesday, every week, you can tune into a webinar from JFrog about mainly Artifactory, starting from not the familiars of Artifactory and all, and going all the way to a very advanced and enterprise features of Artifactory.

We are doing tons of events in November as well, and we’ll be more than happy to see you there, whether you are in the Bay area, they come to meet at Cuban San Francisco or come to hear me speaking at O’Rielly’s Software Architecture in San Francisco. If you are in Europe, W-JAX in Germany and Devoxx Belgium, we will have our presence there with booth and sponsorship in both events. We’ll be more than happy to meet you there. We also restart our meetup program in the JFrog office, and that’s because we have a new office now, and we will be more than happy to see you here, close to here. And of course, give you beer and pizza and good content as well. First meetup is coming on November 15th, find us on meetups, meetup.com, JFrog Silicon Valley meetups group and register and come. With that, I would just, I think, let me check something. I think due to a technical problem here, we lost our questions. Yes, that’s very unfortunate. Oh, okay. Here we go. We didn’t lose them. Let’s see what we have. Okay.

Yeah. The question is how the users, and let me rephrase it a little bit, how can we make it easier on users to know or to guess which options available? What are the arguments, what are the commands and generally what you can do? Mark already showed how you can use help for that. And I also hope that we’ll add a tab completion very soon. You’ll go JFrog tab. It’ll give you RT, BT and all that and then you will have upload, download and all of the options, but also notes definitely can be added as well. And [inaudible 00:48:21] maybe you have something to add here and how can we make easier on the users to guess what they can do.

Sure. Can you hear me?

Yes. Loud and clear. Welcome.

Okay. Hi everyone. First of all, we have a very good documentation. You can just search for JFrog CLI and we have a documentation for all of the products: Artifactory, X-ray, Mission Control, which actually documents everything, all the arguments that you can use, all the options. Of course, through the common line, you can see all the options. We’re hoping to improve the actual CLI help [inaudible 00:49:11] to actually include all of the arguments pretty soon. Basically everything is documented, and it should be relatively easy to get to the documentation. Also, if you make a mistake and like [inaudible 00:49:29] an argument, or so the CLI actually displays you the actual URL of the documentation so you can go ahead and actually see all of the command structure so that you can do it correctly.

Awesome, great stuff. Unfortunately, I don’t see any more questions. I hope that because we were very clear and comprehensive instead of thinking that no one understood anything, that will be the other option. But I’m sure we were just fine and you don’t have any additional questions. But I would like to take the additional couple of minutes that we have, and maybe, [inaudible 00:50:11], you want to add something or maybe highlight a little bit what we should expect in the future versions, where the development is going, what we should see soon enough from JFrog CLI?

Sure. We are going to continue and enhance the CLI with more options. In the near future, we are going to see more build promotion options, including distribution repository capabilities from the CLI, enabling you to use the great distribution features on Artifactory, allowing you to publish artifacts directly from your Artifactory [inaudible 00:51:00] to Bintray. A lot of other plans and features coming ahead so a lot to look for.

Awesome. Okay. Yeah, distribution feature is definitely something that we all look for. It’ll make the promotion pipeline that Mark showed in the demo even more streamlined. We will be able to then distribute files directly from Artifactory to Bintray using the JFrog CLI without actually having them go through local download for the purpose. That will be just great. Me personally, I’m looking forward for that as well. Okay. I guess with that, we are done and the time is also applies that, so thank you very much for attending this webinar. Mark, thank you very much for running the demo and, [inaudible 00:52:10], for your insights. And we’re definitely looking forward to see all of you in future webinars, meetups, conferences, all the things that I mentioned. Thank you and see you soon. Bye. Bye.