Selenium – stories

Blog: How to delete your master branch

Thu, 27 Aug 2020 00:00:00 +0000

At the Selenium project we practice trunk based development, in which trunk is the usual name of the default git branch of the repository. However, when the project was moved to GitHub, the repository followed the traditional use of master as a name for the default git branch.

With the intention of making the Selenium project an even more inclusive place where everyone is welcome, a decision was made to use trunk as the default git branch and, after the switch, delete the master branch. This change created a few challenges. This blog post will point out a few things you should watch out if you want to make the same change in your GitHub repository.

Broken Links

It is common to link specific parts of the code in the documentation, and that link normally contains the branch name. Double-check your documentation for links pointing to files living on the master branch, as they could end up as broken links after the change.

Mentions to the branch name

Similarly, the branch name gets mentioned in different parts of the repository, such as code comments, contribution instructions, issue and pull request templates, and the readme. Don’t forget to check these places.

GitHub repository badges

We all like to show off how our GitHub repository is doing by adding as many badges as we can. In many cases, those badges report a build status that depends on the branch where the build was executed. Make sure your Travis/CircleCI/GitHub Actions badge is pointing to the new branch.

Continuous Integration setups

A good practice in open source is to have a continuous integration setup to run the builds, execute tests and potentially do automated releases. Nowadays, the CI configuration is done in files (e.g. .travis.yml for Travis), and one important piece of that configuration is the name of the branch where the build should be executed. Similar to the previous point, double check that your new branch name is property configured in your CI integration.

Build scripts

At the Selenium project, we have a few custom build scripts that get executed through the continuous integration setup. An example is the script that generates the docs for the Java, Ruby and Python bindings. This script needs to know the code’s branch name to generate the docs. If you have scripts with similar purposes, check them after changing the branch name.

Open pull requests

All of the tasks above could probably be achieved with a text editor and a massive, but careful, “search and replace” across all the files in the repository. In short, the process we followed to move to the new branch trunk was:

Create a new branch called trunk, based on the master branch.
Do all the items described in the previous points.
Commit and push those changes.
Delete the master branch.

Nevertheless, one thing happened that we did not expect: after deleting the master branch, all the open pull requests got closed. This made sense, since they were all targeting the master branch. Therefore, before deleting your master branch, double check and, if needed, edit the open pull requests so they target the new branch.

It goes without saying that the name of your new branch can be any name that works well for your context and environment. For example, the repository that has the contents of the Selenium website uses now dev as the branch with the website source files and publish as the branch with the generated static website that gets published.

These are our lessons learned during the process of deleting the master branch in all the major repositories under the SeleniumHQ GitHub organization. I hope they are helpful if you decide to move from master as a name for your default branch.

This was originally posted at https://opensource.saucelabs.com/blog/how_to_delete_your_master_branch/

Blog: Selenium 2.0 backend for running IDE test suite via the Se2 Firefox

Mon, 09 Aug 2010 00:00:00 +0000

The GSoC 2010, it’s a great adventure.

I’m Raynatou, I come from Burkina and do my internship at SERLI. Like all interns in this company the topic of my internship focuses on advanced topics like the integration of WebDriver as backend for Selenium IDE. Selenium IDE is currently built upon Selenium Core for interacting with web pages. Selenium Core has several major limitations, including the inability to fire native events. To avoid these limitations and produce more robust tests, I am investigating Selenium IDE to using WebDriver in place of Selenium Core.

I’m mentored by Eric Allen from SauceLabs, my lead mentor, and by Jérémy Hérault from SERLI, his second but not least ;).

Eric has already done most of this integration earlier this year. The goal of his work is mostly to show what’s possible with Selenium IDE and the Selenium 2.0 Firefox driver. It is based on an asynchronous communication between the Firefox WebDriver extension and Selenium IDE, Se-IDE waiting for that WebDriver says to him that the current command has been passed with success (or not) to call the next command of the current test case (use of callback function). The goal of my mission is to finalize this integration. However, Eric being a crazy man, and he has done it quickly and together we though to another way to do this merge.

Our new thinking is based on a synchronous communication between both of them. To do it, I get the FirefoxDriver instance and play with it like a normal object, by calling its methods. But the behaviour of FirefoxDriver isn’t as simple as I was thinking. JavaScript being a powerfull language (yes, it can make you shiver), I’ve had just to replace some objects (like Response object) and to use a Proxy (and a bit of IoC-like code) to simplify my life and the code to do. You can see my work on GitHub and follow it.

Currently, I think that more than 95% of the Selenium API commands are usable with WebDriver as backend in Selenium IDE. The process was basically to go through the seleniumemulation package and port all of the Java classes into JavaScript methods on the WebDriver class.

Now, I’m working on Unit tests to cover any of the 2.0 work I’ve done. I managed to get all of the Selenium Core tests to run through IDE. I’ve some refactorings to do to optimize the code and add more comments for a bigger comprehension of my work. I have almost finished.

I hope you enjoy what I’m doing and we hope (me and my mentors) that this work can be included in the wave of Selenium 2.

Blog: GSoC 2010 – Remote Storage

Thu, 15 Jul 2010 00:00:00 +0000

What’s new for Selenium this summer ? The GSoC of course !!!!

I’m Jérémy, a french engineer and I work at SERLI, a services company based in France.
I’m working on Selenium since a year and this summer I’m mentoring Aleksejs for the GSoC 2010. I’m helped by David Burns when I’m on vacation or offline. His experience is really useful to me, and David is involved on student supervising regularly.

Aleksejs comes from Latvia in Europe (yes I know you know but perhaps Geography wasn’t your favorite subject at school ;)). His work was initiated by Patrick and myself. We thought to a remote system that allows Selenium users to save and get remote test cases, directly with Selenium, without any other installations like SVN.

What’s better than record a test case with Selenium IDE and save it on your remote storage? what’s better than share your test cases with colleagues without any other installations, just by using Selenium IDE or a Selenium Remote Storage client?

For myself I don’t know what’s better 🙂

Aleksejs has already coded the server side of the remote storage mechanism with all the necessary unit tests. He has also created a web interface to use it directly through the browser. With his work, you can put, get and delete a test case, and you can also browse the directory where test cases are stored. His work has been done in Java, and he used JSON, for data representation for the communication protocol. This system is really simply to use, based on REST technology, you only have to call URLs with the good parameters.

The next step of his work is to create a Se-IDE plugin based on the API done by Adam (thanks to him). This part has to be done in less than a month and I think it’s a hard task, but it’s so cool to write your own plugin. In this case, Aleksejs will use JavaScript, AJAX and XUL technologies. It’s really good to learn a lot of technologies for its own culture, it’s so trainer.

I hope you’re enthousiastic to get this new feature, but wait until October, when the work will be finalized 🙂

Enjoy guys, Aleksejs, David and I are ready to discuss on it if you have any questions. And good luck with the end of this adventure Aleksejs.