GitLab GitLab Group Kickoffs - Verify:Pipeline Execution (formerly known as CI), 15 Jan 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: GitLab 12.8 Kickoff - Verify:Continuous Integration

Description

Full 12.8 scope can be seen at https://gitlab.com/gitlab-org/gitlab/issues?scope=all&utf8=%E2%9C%93&state=all&label_name[]=group%3A%3Acontinuous%20integration&milestone_title=12.8. Complete GitLab kickoff document is https://about.gitlab.com/direction/kickoff/.

A

Oh, hey everyone. My name is Jason money and I'm. The product director for CIC, be here at get low. Today, I'm going to be talking about what we've got coming up for our verified group, in particular in the continuous integration team, which focuses on CI pipelines and all of the great components that go into making those pipelines work well, which are then used by CD and other parts of the gate level application. So there's four main issues that make up this release that are most important.

A

The first is allowing CI CD mirroring to handle github Forks. The second is allowing needs the dag keyword to handle jobs in the same stage, an allow failure, action for pipeline rules and supporting includes via artifacts, so starting with allowing CI CD mirroring to handle github Forks.

A

What we're doing here is adding support for forking workflows when you're using an SCM provider of github right now see I won't run if you're operating on a floor, that's or on github, but we're changing that so that that works and will support more kinds of forking workflows, which of course, are super common in open source and other development models allowing needs to refer to a job in the same stage.

A

So if you're not familiar with our directed acyclic graph implementation within gitlab CI, you can now break the way that all of the dependencies work within a pipeline. So if you're used to working with a normal pipeline, you know that your first stage will run everything within that stage will run simultaneously when all of those are finished, it will start the next stage and so on what needs you can break that you can build relationships between individual jobs.

A

At the moment, though, needs can only refer to a job, that's in a previous stage, which handles the most basic use cases, but isn't as flexible as it needs to be in order to really handle the you know wide variety of use cases out there, so in this way, you'll be able to have a job refer to another job within the same stage as a dependency which will give you a lot more flexibility and make it possible to configure your dag in new and exciting ways allowing failure action for pipeline rules.

A

So we've introduced this new workflow rules setting which allows you to not just workflow rules the pipeline job rules as well, which is a more flexible replacement for the only accept syntax that you might be familiar with. What we hadn't added support for yet was an allow failure. Action which would allow in that in the case where that rule was invoked, the job to fail, and so this gives you more flexibility in determining when a job can fail under what scenarios that's allowed and what scenarios that's not allowed.

A

This also works with the deck in interesting ways and how we determine whether the the subsequent jobs will run as part of a dependency relationship in that dependency graph and then finally, supporting includes via artifacts. So this builds on some other features in child-parent pipelines, which should be coming out in our 12ax7 release where a pipeline can trigger another pipeline and that child runs. That pipeline runs as a cell pipeline or child pipeline to the one that triggered it. A really interesting use case there.

A

That's not supported out of the box, initially is dynamically generating a get lap see. I am all for that child pipeline. If you're able to do that, you're able to do a ton of really interesting and power powerful things in your pipelines, you could, for example, iterate over. A number of you know targeted targets that you build to target our target, architectures different versions that you build and build out a matrix on the fly that can then be built in child in child pipelines. You could do any kind of customization where the pipeline starts.

A

It needs to do some things analyze. What it is built and then trigger. You know a child pair, a child pipeline to do something that's dependent on what it's done. So this feature in and the way this feature works is that it actually passes.

A

We include via an artifact from to job, so you have the job that triggers the child pipeline and it will get its gitlab CIA emeralds from an artifact from a previous job that RIA, which you can see here, but this is just going to open up a world of powerful features within the get lucky IMO and get. Let's see, I I'm excited to see what people build with this and I think it's gonna be really powerful.

A

It's gonna be a nice way to implement some of these things, that's better than, for example, implementing a matrix keyword or something like that. That would allow you to do matrix builds. This is just more powerful, flexible, easier to understand and doesn't add to the complexity able to get. Let's you know yeah so again, really really excited to deliver this one and I can't wait to see what people build feel free to jump into the conversation on this one as well. Issue number is three: five, six three T we would love to hear.

A

Are you gonna use this in order to make sure that we can support those these cases? So hopefully you saw something in that that you liked again we'd love to hear from you. If you got any feedback on any of these items and thanks for watching.