Hi this is Brian Walt at gitlab and today, I'm going to walk through a feature request that I'd submitted to enhance the work-in-progress mode of a merge request. So today, the work-in-progress mode, which is denoted by having this whip tag in front of the title, prevents the ability to have a merge accidental, merge or merge into the target branch until this work-in-progress mode has been resolved.

This provides a developer, a sandbox area where they can very quickly pick up an issue and start working on the merge request before even writing any code, which means that, as they submit new, commits they're able to see real-time feedback from the CI pipeline on the code that they're working on inside this dis merge request.

So this is very valuable for development teams in general, because that one allows the developers to know you know what features or issues are currently being worked on, but are not quite ready for review yet, but also provides that space for you to work through an issue without having to do everything on a local environment.

Now, to enhance that, let's take, for example, this merge request. I have up here, which is currently in work-in-progress mode. This missed merge request is to resolve a 500 errors with the API endpoint. The users API endpoint and I can see that as I've committed. My first commit that it indeed does fail. The Veii API validation test. Now this job does happen pretty early on in the process, but I have all these other jobs that are part of this. This branch's pipeline, but I, don't necessarily need to resolve this.

This particular issue so to avoid having to wait for all of these jobs to complete before I can get my results. It would be very valuable if I could just selectively choose which jobs that I need to have for me to validate this this issue and start to work through it much quicker.

The idea is what I've calling a working session and what working session does is allows you to individual jobs as part of the default pipeline that comes from your gitlab CI llamo file and and modify those without actually having to modify the the llamo file inside code. So when I click this working session on the pipeline's dashboard I'm, seeing all of those jobs that are predefined in that llamo file showing up here and you can see that by default, they're all turned on well for my particular use case here.

I only really need to get through this API validation test and maybe make sure that my code quality is up to standards with that as well. So I can go ahead and turn off all of these other jobs that are not necessarily relevant to what I'm doing as part of this particular feature enhancement or our bug fix. Rather so, once I've turned off all these other jobs and I enable the work-in-progress pipeline.

You can see immediately that it kicks off a new pipeline, but this pipeline only consists of those jobs that I have defined in the working session itself. So what this allows me to do as a developer is resolve this particular issue without having to wait or waste resources and runners performing against jobs that are not necessarily relevant to the work that I'm trying to do in this particular case and when I'm done with that feature, I need to get all those pipelines back in make sure the actual the full pipeline runs.

So I can simply do that by resolving the work-in-progress status, which will revert this back or resetting. This pipeline will also revert that pipeline back to its original state.