 All right. Well, thanks for coming to our third tutorial session for this Q3 hackathon. I want to welcome Tim and thank you for talking about GitLab package stage. It's a new topic that a lot of people probably don't know about. So, Tim, I think this would be a great opportunity to not only give us an overview, but where community members can help and make GitLab better. So, I'll turn things over to you and feel free to share a screen. Thanks, Ray. I really appreciate the chance to talk to everybody today about some of these features. I'm going to, I have a short roadmap presentation that I put together. I cover some items that are open for community contribution as well. And just going to share my screen, and we'll do a short demo of the container registry as well. And, Ray, can you see my screen okay? Looks good. Cool. Let's start out with, okay. So, I'm Tim, the product manager for the package stage. And we are basically responsible for the container registry, the and our different package manager integrations, which includes NPM and Maven. Conan is coming soon, launching in a couple of weeks. And after that, we'll be working on NuGet, which will help support .NET developers. So, really, what is the package stage? It allows you to publish, consume, and share packages in any languages, in any language, all in one place. And you could do that using the specific client, like the Docker client, which I'm going to show off today, how to use that with the container registry. You could also use GitLab CI, CD, and be able to publish these packages. So, for us, our north stars are the universality of the product. We want to be able to support all different languages, not just Maven or not just Java and JavaScript. We want to support Python, RubyGems. There's a tremendous value in us supporting all the languages that our users need. It has to be secure and accessible. So, for us, that means providing a unified method of authentication using the GitLab personal access token. So, you could simply authenticate with GitLab and connect to any of the different package managers that you want to. And then providing a performance supply chain. So, many of the packages that users rely on are downloaded from external sources, of which there may be downtime or they may be open source vulnerabilities. So, providing caching and proxying and caching of dependencies for faster build times. And in the future, providing some more security firewall features to prevent any vulnerabilities from entering into your supply chain. Okay. Oh, I guess I'll do the demo right now. Okay. So, I just wanted to give before a little context for the container registry. I have this group that I've set up here with container registry examples. I have this project called container registry one. And just to give you an idea of overview, you know, I have this project. Many of you are familiar with the GitLab CI ammo file. This is the recipe for CI CD pipelines. It includes a Docker file. And then the app itself is really simple. It's just going to open up and say, hello, it's Tim. And I'll be able to and it'll show which host it's being hosted on. So, let's start with maybe making a small change here. Get rid of this guy. I'll just add my last name to the hello, it's Tim. And commit changes. Okay. So, now, because I have in my GitLab CI ammo file to automatically run a test and build a new image on commit, I have a pipeline that's running now. So, if I go over to CI CD, I can see my pipeline running. And this is building this image now. Alternatively, I could also do the same thing from the command line using the Docker client. So, here, I'm CD'd into my specific project here. And I could build a new Docker file just using the standard Docker build and Docker push commands. So, here, I'm going to say Docker build. Okay. And then I can also do run a Docker push here. Okay. And now, if I go back to the container registry page, which is under this packages container registry, I could see we just pushed this tag just now, this merchandise tag. And I could also run it by saying Docker run. Okay. So, this is running. Let's get a view of which containers are running on the system now. I could see here that the ID is 0AA408. So, let's see where. And here it is. Hello, it's Tim and 0AA4. So, it's the same image that is running or the same container, I should say. So, we just built and published a container. Let's go back and check on our CI CD pipeline, which finished successfully. And so, we should see another image pop up in our container registry as well. That will probably be here. And we could see latest was updated a minute ago. And this came from CI CD. So, a couple of things that we're working on here is improving this user interface. We recently added the ability to select multiple images for deletion. We're going to be adding more things like sorting and search in the future. Okay. So, I just wanted to give a quick overview of how you could use, how you could build, publish, and consume Docker images using GitLab. And let's go back into the presentation. Okay. So, I did want to talk about the roadmap. So, what are, what themes are we addressing in the coming months in the package stage? The first and most important theme for us is lowering the cost of the GitLab container registry by introducing storage management features. What does this mean? For a lot of our customers and for GitLab ourselves, we have not, we don't have a lot of features for cleaning up the container registry, for programmatically untagging images, and for running inline garbage collections. So, that's a big, highly requested feature for us. Many of our customers and users are asking for this. And I'll dive a little bit more into what that means in the upcoming slides. The second theme spans multiple container registry as well as our other package manager integrations. We want to improve usability by standardizing authentication and functionality. The idea is we want parity across all of our different integrations. That means that you should be able to always authenticate using your GitLab personal access token. It means that you should expect the same functionality from integration to integration, meaning that you could build and push images or packages using the client or CI, and all of it should just work. We've made a lot of progress on this theme in the past months. And then we want to expand our user base by integrating with additional highly requested package managers. And we'll go over what that list is in an upcoming slide. I suppose I should pause here. Are there any questions? Ray, do you have any questions? No, I think we're good. Okay, cool. We'll keep going. Okay, so what have we done in the past three releases? One of our, when I started in April, so over the past few months, when I started, I noticed that our MPM registry was a source of negative customer sentiment because authentication didn't work. Subgroups, we didn't support subgroups. So for many of our enterprise customers, they were blocked from using this because they're using groups and subgroups. So in the past few milestones, we've enabled groups and subgroups. We've improved the image deletion process for the container registry. And then we've improved authentication for MPM, adding support for the GitLab personal access token. We've improved the navigation for the overall the package stage before this. The container registry and the packages were all under separate navigation items. It's all centralized now. We are slowly adding more features to our API, both for the container registry and for the package registry. So now you can list the images in a group. That's important because next, we'll be able to create a front end for that view. So you'll be able to view all the containers or images, I should say, at the group level. And we talked a little bit about the multi-select the lead for the container registry UI. So that's what we've been working on. Okay, so what will we work on in the next six releases? It's like wherever that is, it's in the way. Okay. So for the container registry, like I mentioned, a big piece of what we're working on is the storage and management features. So we want to give users the ability to delete images from CI. The way that we'll do this is we are updating permissions for CI registry user to not only be able to build and publish images, but to also be able to delete them as well. That work is almost done, should be coming out the next couple of weeks. I mentioned the improved image deletion. We added the multi-select last milestone. Now we're fixing a bug with Docker where if you delete a tag, it will delete all tags with the same image ID, which is problematic for users in an unexpected behavior. So we're actually pushing a change to the Docker API to resolve that. We have built a few milestones ago. We built an experimental command for Docker pruner, which will clean up the container registry. So in the upcoming milestone, we want to take that from experimental to production-worthy. We've seen some of our customers be able to use this, and it works fine. There's some bugs. We need to be able to make sure this is production-worthy, and this will really provide a streamlined garbage collection process, and hopefully we'll run much faster and much more efficiently than what we currently have. Tim, I assume these also listed on your product directions page by any chance? Yes. Thank you for exactly. So all of this information can all be accessed in our product vision package, which includes what are our North stars? These look familiar. This is the information at the top of the presentation. What are our categories? And if you drill into each of these categories, you'll see all of the same information I'm showing to you now. I just wanted to make a presentation for that. Perfect. So if anything gets updated, people have the latest in the handbook. Exactly. Always go to that. This is more of a snapshot. Yeah. Thanks. No problem. A couple of other things that are worth calling out. A new API for bulk removal of tags at the group level. Right now, the API is limited to the project level. So for system administrators that have many groups and many projects, this is problematic and time consuming to remove tags across many projects. So giving some group level ability there will be really valuable for cleaning up the registry. And then some more features maybe worth calling out down here is how do we expire images from CI? So currently for artifacts, for instance, you could add on a line to your GitLab CI ML file that says expire in seven days. We'd like to do the same thing for images and tags. And then as we've improved the garbage collection command, we want to enable users to run and schedule it from GitLab without having to run it manually. And then we want to add in more retention and expiration policies which will allow users to programmatically decide how images and tags are removed and deleted. Okay. For the package registry, so this is all of our package manager integrations. Up next, we're actively working on Conan, which is for C and C plus developers. This should launch a milestone 12.3 and we're really excited about it. Right after that, we'll be working on Nougat for .NET support. And then we have a couple of things. So we want to add CI authentication for NPM. That's, we mentioned the theme earlier of standardized authentication and bring parity across these features. This is a key missing feature that we'll be working on in milestone 12.4. And then a couple of other small things. So a new API to list out the packages at the group level. That'll be, again, a nice change in something that we're doing for the container registry as well. Supporting subgroups for Maven. This is another key parity feature, making sure that we are supporting our enterprise customers or people who have many groups. And then the same thing. Maybe you're seeing a theme now, CI authentication for Conan. The dependency proxy is basically allows users to proxy and cache Docker images. It's in a pretty, it's in minimal phase right now. In order to bring it to viable, we need to add authentication support for private projects. And we need to give some more management controls to allow users to delete items or purge it entirely. So this is what we're working on over the next six releases. And again, it's really addressing those core themes of storage management, usability and authentication and net new package managers. Okay. So in the spirit of GitLab and everyone can contribute, what are some ideas that people can contribute to during the hackathon? Well, we have this issue published to a group based Maven API endpoint. Currently, we allow for pulling pack dependencies at the group level, but not publishing. So this could be a really good first contribution for people. Auto rebuilding Docker images in the container registry when the baseline image is updated. This is a highly requested feature, something that we definitely want to tackle. Maybe a little more advanced, maybe not for your first contribution, but this would be something that I think would be a really fun project. Another one for first contribution maybe is an example Docker image to check the setup of the container registry. So basically once you connect and authenticate to Docker and set up your GitLab container registry, basically that you have a Docker image prebuilt in for you to check the setup. And then finally showing container registry push events in the GitLab activity feed is would be another valuable thing. So when a new image is pushed or updated, basically showing that detail on the activity feed for people to consume. Yeah, I definitely appreciate that, Liz. And I mean, people typically ask for a starting point on where they can get started in different product stages. This is great. And in case people are watching the recording after the hackathon, if these issues haven't been taken up during the event, I mean, obviously, you're welcome to raise your hands and just mention me or Tim, and then we'll do our best to help you out as you work on an MR. Perfect. Thank you. Sure. And just real quick, I wanted to give an overview of what's coming next in terms of package manager integration. So we mentioned Conan and Nougat. After that, we're planning on PyPy to support Python developers, then RubyGems, then Helm charts are next three. And how does this compare to GitHub's package registry? They have some of these integrations, but the feature is still in beta. So we're hoping to launch some of these in the coming months. Okay, I could just go through, quicks these updates. So for the package registry, we mentioned Conan and Nougat, we mentioned subgroup support for Maven. We also have some UI improvements that we'd like to make. So allow for sorting of the packages list and allow it to delete files from the packages UI. For the container registry, we're also conducting user research. So we're currently surveying system administrators and developers to understand the required metadata for the container registry. And I can take a minute to talk a little bit more about that. So here in our container registry UI, we're showing some very basic metadata. We're not really taking advantage of the fact that this image we built a few minutes ago from CI, and we're not showing which commit it came from or which job ID it came from. So understanding what metadata would be useful in this table through survey and user research, and then actually doing the work to make sure that it's populated here and that we're helping users as much as possible. And a couple more slides here. The dependency proxy, you know, really we're just planning the next set of features for broad support and adoption of this feature. It's pretty early on. It's still in the minimal phase. It just might be more towards the end of the year that we start to work on this. And for Helm charts, again, a similar story. Helm v3 is coming out in the coming months. Azure DevOps supports announced Helm support with their container registry. We will probably do something similar as Helm v3 is changing how it operates to use a container file or container registry as storage for the Helm chart. So we'll probably do something similar. We're just doing some user research on that one as well. And then just in terms of people. So we had five new hires start between July and August. The package team today, we have three engineers. We have two managers. We have a product designer and a product manager. We have a new engineer starting in October and we're looking to hire another Go engineer. So if you are interested in, if you know Go and you're interested in working in this stage, definitely click through that link and see if you can apply. Okay. I think that was the presentation that I had and the demo raise or anything else that you think that I should cover? No, I mean, I really appreciate this. I mean, not only providing an overview of your team and the product stage, but also where and how people can start contributing. And I know there are a few other folks on the call, like if you have any questions, feel free to go off mute and verbalize them or type them in the chat window and give people a few more minutes. And yeah, I'd also appreciate on your last slide, like listing not only you, but other people in the package team that people can ping if they have any questions on issues or MRs. I mean, this is a reminder that I give probably almost every tutorial session. Pinging people at GitLab is a completely fair game, a fair thing to do if you have any questions. We're all part of one community. We don't distinguish between whether you're working in GitLab or not. If you have any questions on issues or need help on MRs, feel free to ping anybody listed here or myself. It's true. We love it. And as a product manager, I totally rely on feedback from our users and from the community to make sure that we're building the right features and that we're moving as quickly as possible and that we understand our users' needs. So definitely reach out if you have questions or feedback or anything like that. I'm always happy to talk to our users. And I was also checking merge requests in CE in terms of community contribution and I searched for container registry. It looks like there are two MRs that are in progress for 12.3 and one was merged for 12.1 and coupled before, like a previous to 12.0. So it's not a completely green territory. I guess people have been contributing. I definitely want to see more of it, I'm sure. Yeah, exactly. And we have a couple of contributions to integrating new package managers. So someone has an MR that we're reviewing now for adding in support for Composer, which is the PHP package manager. That's another one that we want to push through and we really want to make it so that other people can contribute as easily as possible and add other package manager integrations. So we're definitely interested in that as much as possible. We love the community contributions. All right. It doesn't look like there are any further questions, but obviously this slide set is already posted, but the video will be posted on the Hackathon page as well. So if you weren't able to join the session, hopefully you'll have a chance to view this and then Tim or myself with any questions. And thanks again Tim for making the time. Really appreciate it. No problem. Thank you. All right. Thanks.