Here at Ghost Inspector, we’re continually rolling out changes that we think make our customer’s lives better. Occasionally that means undoing some bit of logic we created or allowed in the past in order to move the product in a direction that makes it more powerful for everyone.
We have a couple of changes coming next month that we think are going to be helpful to our customers, but they do change how some logic currently works. We want to make you aware of those changes and have outlined them below. Additionally, with regard to the variable name and AWS CodePipeline changes below, we’ll be reaching out to customers directly who we believe will be impacted by these changes and helping them to adjust ahead of time.
Variable names that match reserved parameter names
Ghost Inspector variables are a super useful and flexible tool for customizing and storing data on the fly in your tests. In general, we’ve left the naming of variables open-ended and you can use any names that you’d like. If you’ve executed a test or suite using our API before, then you know we offer a number of parameters for customizing things like browser and region (geolocation) on the fly. When one of those reserved parameter names is passed into the API, we also apply it as a setting to the test. For example, passing in a region parameter to a test run will both create the region variable and it will also override the “region” setting of the test run.
This behavior is not currently consistent for variables defined in the organization’s settings, suite’s settings, or within data sources. We’re going to update the system so that it becomes consistent. Currently, if you have a variable named region in your suite settings or within a data source (whether that be a data source stored in the service or a CSV file that you upload), it will only be created as a variable in the test run. It will not override the “region” setting of the test run. We’re updating the system so that the setting override will occur. This will make the logic consistent with the API and open up a really useful option for test settings to be customized in different ways within a data source. For instance, you could have a browser column in your CSV file that specifies which browser version should be used during each test run.
If you are using any of the 3 variable names below, and you do not want the behavior described above, simply rename the variable to something else to avoid the collision.
browserregionviewport
For instance, instead of using a variable named region, you could use regionName or testRegion. If you are using these variable names and do not make this change by February 14th 2022, your tests could begin running with unintended browsers, geolocations or screen sizes.
AWS CodePipeline geolocation settings
When we launched our AWS CodePipline Integration years ago, we set up the logic to automatically run your tests in the same AWS region (geolocation) as the pipeline that triggered them. This meant that if a pipeline running in Dublin, Ireland (eu-west-1) triggered a suite of Ghost Inspector tests, our system would automatically run them from the same Dublin, Ireland geolocation on our end. Neat!
While this was a nice bit of logic in theory, it now presents a challenge because it overrides the geolocation settings that the user has chosen for their test or suite. This makes it difficult for a user to execute the test or suite outside of the geolocation where the pipeline is being triggered. It requires them to override our region matching logic with a custom override parameter of their own, which isn’t very user friendly. In short, we’ve realized that this default behavior isn’t actually convenient.
As a result, we will be dropping this behavior and simply running the test or suite using the geolocation defined in its settings. The region matching behavior will instead be “opt in” which you can do by adjusting the settings of the test or suite, or by adding the custom geolocation parameter yourself in the pipeline.
Old browser versions
The two browsers that we currently offer for test running, Chrome and Firefox, have had auto-updating capabilities for years now. This means that pretty much every user out there is running the latest, or near latest, version of the browser on their system.
We’ve been maintaining a lengthy backlog of old Chrome and Firefox versions for a number of years now but what we’ve found is that practically none of our customers are using anything beyond a few versions back. This makes perfect sense because you’re ultimately interested in testing from your users’ perspective, and at this point no “real” user is going to be out there navigating your website using Chrome v68 from 2018 unless they’re really jumping through hoops to do so.
With that being the case, we are going to transition to a scheme of maintaining the latest 10 versions of each browser. The ultra-low usage of older browser versions coupled with the resource requirement of maintaining them makes this an obvious choice. We can use those resources to bring you new and better options in the future. If you have tests set to use a browser that is more than 10 versions behind, those settings will be automatically incremented when we roll out new browser versions. The one exception is that we will maintain the “Firefox v60 (Legacy)” option for a short time longer for customers who are still using it for specific purposes.
—
That’s everything! Please feel free to reach out to us if you have any questions or concerns about these upcoming changes.
