GitLab Release Group, 5 Aug 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: [DEMO] Allow parent project's developers to create pipelines for merge requests for fork MRs

Description

This is a demo for https://gitlab.com/gitlab-org/gitlab/-/issues/217451

A

Hello, uh this is a bucket engineering glove. um Today, I would like to introduce you about this uh future. um Allow parent project developers to create pipelines for major requests for four command requests, which will be released in 30.3 gigabyte, 0.3.

A

It's a bit confusing, as it looks at the issue issue title um then taking a look at the problem to solve that as an open source project. Maintainer, I want to be able to allow a specific folk must work as to create a pipeline in the parent project for security reasons. I don't want to allow all folk much requests, as I have secrets that I want to protect.

A

I want to be able to review the changes uh check if they don't try to lick the secrets and only then allow it to run in the parent project. uh It's a bit confusing. But uh the point is that we uh today pro parent project maintenance can run uh pipelines for uh focal market requests. uh In the past it was impossible um folk, mods requests can only create in fork project site.

A

So uh there is a problem that um the pipeline in folk project is not completely not cannot completely be trusted because uh folk project, uh folk, uh personal members, external contributors, can change see a resources that used in four projects, for example, sale, runners, project level, variables, etc. They can change it, so the results of the pipeline could be changed could be different from uh parent pipelines.

A

So uh with this feature you can uh you can create a pipeline in parent site, even if it's for modular guests, so you can verify it more accurately.

A

So, let's get started demo now I'm opening uh two windows. The left side is uh me, as, um as my account at the right panel, I'm logging in as a dummy user, and let's say this is a full contributor and then uh we are seeing that and this contributor has already fought the open source project. This is gillap open source project and then he's trying to contribute to upstream projects in this demo.

A

A

Let's try to open a web.

A

Ide and now we are changing, uh we are making a trivial change as of external contributor.

A

A

A

A

Yeah, so there is her um a small bug in this regular expression, so external conductor fixes it and it commits and they create a new, much request, start new module cast.

A

Oops, uh something went wrong.

A

Well, wow, okay, okay, no way back and now uh this project targets this fork project targets to the upstream project. So let's keep creating. Let's continue creating this much.

A

A

Okay and now the module case is quick product recreated and let's see this much request in my account.

A

A

As you can see this, as I see this warning, and this smart request is obviously a folk modular test uh which is submitted by a folk external contributor, and then uh I can review these changes. I can see the pipeline is running and then look at look at this pipeline um opening up this pipeline page. Sorry, as you can see, this pipeline is created under external contributors namespace, which means this pipeline isn't running in upstream project, but this full project.

A

This is fine as long as you trust the uh folk project, ci resources, but uh today you can create a pipeline in parents projects. So let's try it. You uh I created round pipeline button.

A

Are you sure, when you want to run this pipeline? These are security implications. um As I reviewed this module, I guess it doesn't have as much code, so I can keep going.

A

Okay, now um I created uh the pipeline for monitor request as a behalf of this external contributor, and you can check the pipeline detail page that uh this pipeline is certainly created under gilaf or the namespace group's namespace and, as you can see the difference, there are more jobs in upstream projects, because sometimes parent project provides review apps so that, let's see.

A

Okay, the ruby apps only available in canonical project- uh you can not it's, which is not available in fork project right.

A

So um as a product remember, I can test this fork manager cast in review, apps, etc. This is very this is. This is very nice to that uh verify their moderate gas more accurately.

A

A

um I think this is pretty much it if you have any questions, please see this uh documentation page. um Here's your the section talking about this feature, including security implications, um and uh also this to use this feature. You have to configure pipelines for modular gas at first.

A

This is a bit special pipeline that uh specifically designed for modular guests, and uh it's a bit. uh You need a bit of configuration, but it's it's very easy. uh You can just follow this document, um so if you used to keep using uh legacy branch pipelines, uh it's worth considering to switch to pipelines for marginal guess, it unleashes um some subs subsequent features such as smudge trains, uh which is documented here, uh etc. So you get more um advanced, you can use more other ones to feature with pipelines for watchbackers uh like uh this.

A

This feature, which we just demoed.

A

One point is to add: is that uh this, with this capability um parent project members, ah sorry folk much request can be added to much train as well. uh So um previously much strange was not be able to be enabled on in open source project. Because of these reasons, uh like external contributors, uh the modular gas cannot be added to much rain. So uh it was a deal later uh to enable my trains.

A

But this is not an issue uh today uh you can enable much trains, even if you, uh your open source project, receives a lot of uh external much requests for march records, uh so pretty much it. um Thank you for watching, see you in the next video.

A