Lint checks in pull requests
14 Feb 2022.
When you push a git commit, Stb-tester uses any idle Node in your test-farm to run a “lint” check using Pylint to catch common mistakes in your code before you even run a test.
Previously, we would run Pylint in the cloud. The advantage of running lint on the Stb-tester Nodes is that we lint your code using exactly the same environment that we use to run your code when you run a test. This environment includes any third-party libraries that you install in your setup script, so Pylint will be able to check your code when you call those libraries. For our customers who install in-house libraries from a server on a private network, this enables linting that isn’t possible on a cloud-based runner.
We run Pylint in the background on any idle Node. If you start running a test on a Node that was running Pylint, Pylint will be transparently re-scheduled onto a different Node so that it doesn’t interfere with your tests. All of this is completely automatic and requires no configuration.
Starting today, we are also reporting the lint results using GitHub’s “checks” API, so the lint warnings appear directly in your pull request:
To learn more about Pylint —including how to configure or disable specific Pylint checks— see Static analysis for your test scripts: Catching common mistakes before you run the tests!
To support this feature, the way the Stb-tester Portal authenticates with GitHub has changed. The next time you log in you will see a dialog like this:
It’s asking for your permission to share your GitHub login name with the Stb-tester Portal (the Portal needs to know it for authentication) and the email addresses in your GitHub profile (the Portal uses this for the “author” information when creating commits on your behalf, for example from the Object Repository’s “Add New Page Object” wizard).