GitLab Plan Stage - Speed Runs, 17 Jun 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: GitLab 13.1 Introduces the ability to satisfy requirements through test

Description

This video demonstrates the MVC of being able to satisfy requirements through testing. At present, this feature allows for an all or none approach to satisfying requirements, but we are working hard iterating on this feature to make it even more powerful.

The epic describing this feature can be found here. I would encourage feedback to be left there, or on the individual issues within the epic!
- https://gitlab.com/groups/gitlab-org/-/epics/2859

If you are interested in reading the documentation shown in this video, please look here: https://docs.gitlab.com/ee/user/project/requirements/index.html#allow-requirements-to-be-satisfied-from-a-ci-job

As always, please feel free to reach out to the Plan:Certify team with any questions, or to discuss future plans!

A

Hello, everyone and welcome this is a quick speedrun of new requirements. Traceability features that we're offering in the 13.1 get lab release we're very excited about. As you can see, this is a list of our requirements and then a requirements, management project that I've created just for demonstration purposes, you'll notice something a little bit different. We now have these green air boxes here that say satisfied at some of our requirements. I'm gonna explain how that works.

A

Now, one of the goals of requirements management is to be able to trace your requirements to tests and then satisfy those requirements through testing. This then feature in its infancy. So it's the first iteration of this one super excited about how this works. So within your project, you have your requirements. Some of these, you can see, are new and or are not satisfied. Others, you can see, are satisfied in order to implement this or to utilize this.

A

What you do is you'd go to your CI pipeline configuration file here, which is the gitlab CI mo file. You'll, add this new section, which is called requirements check, and what this does is. This particular snippet sets up a manual job that does not allow failure and it runs a script which effectively passes a string into an artifact file. That string is basically a all requirements have passed and then it utilizes a built in function that we've created that will take that artifacts file and parse it and satisfy all available requirements.

A

When this manual Chaves is um kicked off. We have documentation here. This works with all the other options within the the CIF config file, so it doesn't have to be a manual job and it doesn't. It can allow failure if you want it to so. You can set this up. However, you want ideally what you're looking for, though, is to get this string, which is star and then past, and what this is telling us is that all requirements have passed now in the future.

A

We hope to expand this, so you can have specific requirements passed and specific requirements not passed, but for now it's sort of an all-or-nothing situation so going back to our requirements here, what we would do is we go to our pipelines.

A

We see that I already ran a pipeline here once it passed so now. I can go back to this pipeline and see that there was this job and I had clicked pass on this job or plate, which basically runs the manual job. Now to run this again.

A

We should be able to go back into here into pipelines and say, run pipeline run for master and that's fine. We hit run now you'll see that I have a sort of a dummy test in here right now to show that this can be run after other tests have run right now, it's pending and we'll wait for it to complete.

A

A

This is really exciting, for summers were trying to tie their testing to their requirements, and this shows the initial steps were taking toward that. It's really gonna be a fantastic opportunity that, when your tests can actually satisfy a requirement, so you go to your requirements list and see which tests or which requirements were satisfied by testing. That's a major step forward for us and our requirements. Management implementation you'll see that now this is passed and we have this manual requirements check and if you hover over it, it says manual action.

A

So if I just hit play on that and say, ok, those tests have passed, I will go ahead and hit play you'll see that it kicks off that requirements, job that we talked about that was created in the CI yeah Mel config file.

A

This takes a moment to run and when complete, we can go back to our requirements list and see it. We should now have a satisfied next to every requirement, because this would say that all requirements have been satisfied.

A

Well, this is run is take a moment to say that if you have feedback on these issues, we'd love to hear it. You can always welcome to go out and look for these issues within the public repository of gitlab and add your comments, your feedback there. It's greatly appreciated you'll, see that this is now passed.

A

So if we go back to our requirements list, what we'll see is that everything now is marked satisfied because, again being all or nothing all requirements have been satisfied and if I hover over this I can actually see when it passed when it was satisfied. So I can tell which pipeline three dates, or when was last time that pipeline was run and how these passed I have any questions at all.

A

Please feel free to contact us where we'd love to hear your feedback, we'd love to hear ways you can see this being used in your organization. Thank you very much.