GitLab Quality Department, 4 Dec 2019

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Looping pipeline demo 2.0

Description

Walkthrough of the tool and how to set it up

A

This is a demo or walkthrough of the looping pipeline test tool. I'll go over what it does and then explain how to set it up. Turn against your get lab instance. The looping pipeline runs a select set of end-to-end smoke tests simultaneously and continuously against a live get lab instance. The purpose of this pipeline is to be a testing tool to test the uptime of an instance.

A

For example, during an upgrade event, it can run against a single instance or a Geo instance the tests that it covers our smoke tests, which, by definition, cover the critical functionality only one job that runs the entire smoke test suite. But then we also have specific jobs for certain smoke tests, including login creation of projects, issues and merge requests also pushes over HTTP and SSH.

A

If you're testing a Geo instance, all of these tests, I just mentioned, will be run against the primary node and in addition, there are some geo specific tests that test geo replication of HTTP and SSH pushes to either the secondary node or the primary node.

A

So here is a pipeline that is currently running. You can see here the separate jobs for the different tests. If any of these tests fails, the person who triggered the pipeline will receive an email that indicates the pipeline's field and also lists the specific jobs that failed.

A

Going back to the pipeline you'll notice. There are two steps or two stages: a lot of resources are generated during the test stage you can see here. This is the instance. That's currently being tested, ence there's a lot of projects here, regardless.

A

If the test stage passes or fails, the cleanup step will run and it will delete all of the resources that were created during the test stage.

A

So now I'll go over how to get this pipeline running against your instance. The few things you need to do you'll need to have a user with admin access and also create a group which will be a your sandbox group and make sure that the user has owner access. You'll also need a personal access, token or API requests.

A

This is because some of the end-to-end tests use the API to generate resources if you're testing a single get lab instance, you want to make sure that the Geo specific jobs are ignored and on the flipside, if you're running against Joe, and since you want to make sure that these tests are not ignored.

A

Another thing you'll have to do if you're testing a geo instance, is to visit or try to log into the secondary node as the user and authorize the secondary note to use the account. You can see this modal here.

A

Ok, so here is a list of the environment variables. You'll need to set there's a URL of the instance or the primary node, the username password access token for the API requests. We also need to set the loop for under minutes.

A

This refers to the length of time the test will run so if you're, for example, wanting to test during an upgrade event that usually lasts 20 minutes, you'll want to make sure that this covers at least 20 minutes probably longer to safe, and you also need to provide the sandbox name or the name of the group that you created if you're running geo tests, you'll also need to provide an ee license and the URL of the secondary node.

A

You can specify these environment variables right before you kick off a pipeline. So if you go here and run pipeline, you set them here.

A

So let's see how this okay, so it looks like all of the tests passed and now it's in the process of deleting all of the resources.

A

They're still here just pause a minute.

A

Okay, so the cleanup stage has finished and when you refresh this, we should see all of these projects go away. There we go so we cleaned up the campsite and that's it. That's the demo of the looping pipeline test tool.