GitLab Package Group, 22 Sep 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Conan project-level packages with no naming restrictions

Description

A brief demo of the using the project-level remote for Conan packages on the GitLab package registry. This feature allows users to upload and work with packages on GitLab without the naming restrictions imposed on the instance-level remote.

A

Hey everybody: my name is steve. I'm a back-end engineer on the package team at gitlab and today I'm going to show you um how we have implemented a project level conan repository, and what that means is that, with this new feature, you can now upload conan packages, regardless of naming restrictions and I'll show you how that all works. Let me share my screen here.

A

A

All right, so, when working with the cone repository, as I mentioned, uh when you add a remote previously, we were mostly or we were only working with instant remotes. So this was the command you'd run to uh gitlab as a remote, and then you were forced to use a specific naming convention where the user in your package recipe had to be the plus sign separated project path.

A

So if your project was fuselage bar, your username had to be foo plus bar, and this didn't really work very well, because if you have a project that was multiple subgroups deep, you would get a very, very long username and then sometimes that would even exceed the 50 character limit that conan has on its username.

A

So what we've done is, instead of using that naming restriction as a way to look up your project or your yeah as a way to look up your project. We have a new remote you can connect to, and this is just a different url that includes your project id.

A

So let's take a look at how this works, so I have a project set up here. That is.

A

Ready to go, it's totally empty, there's no packages in it yet and I'm going to grab the project id and I will grab this remote.

A

And let's go ahead and add the fresh remote here, so we just need to change out the project id and change it from gitlab.example.com to gitlab.com or whatever your domain is for your gitlab instance, and I'm going to call this one git lab project. Since I already have a gitlab remote.

A

All right now, I'm already in a simple conan project. So now we can create our package just like any other thing, but we don't need to use the naming restrictions. So we can just say like no.

A

Restrictions and we'll call it stable, so that'll create my package.

A

And now we could, we could add a user um to add our credentials or I'm just going to do it in line.

A

um So this is going to be our current username of uh our coding. Username is our gitlab username, and then we have a conan password, which is going to be your personal access, token deploy token or, if you're, using ci it'll. Be your job token.

A

There's many examples in the docs of how you can do this or you can do it explicitly in line like this or by adding a user separately. So I have mine.

A

A

And we're going to upload this recipe.

A

And we're going to do everything to the remote gitlab project, I believe, is what I called it.

A

Could be, this was actually supposed to be conan user yeah just have it username, instead of user all right and there we have the upload succeeded. If we go back to our project, we can come to our package registry.

A

And there's our package and looking a little bit closer, we see that we have that correct recipe, there's no naming restrictions and we can work with it from there by running our installation setting up with this remote all right. I hope that was helpful and please feel free to reach out at s. Abrams on git lab be happy to answer any questions.