Skip to content

Open Source

Announcing Selenium 3.0-beta1

Selenium - Fri, 07/29/2016 - 03:20

At SeleniumConf in 2013, we announced that a new major version of Selenium would be released “by Christmas”. Fortunately, we never said which Christmas, as it has taken us a while to make all the changes we wanted to make! We’re excited to announce the release of the first beta — Selenium 3.0.0-beta1.

We’d love you to try it out on your projects, and provide us with feedback on where the rough edges are before we ship the 3.0 itself! Please remember that this is a beta release, so your feedback is incredibly helpful and valuable in order to help us smooth any rough edges.

For the last six years we’ve been advising users to switch to the newer WebDriver APIs and to stop using the original RC APIs. With Selenium 3.0, the original implementation of RC has been removed, replaced by one that sits on top of WebDriver. For many users, this change will go completely unnoticed, as they’re no longer using the RC APIs. For those of you who still are, we’ve done our best to make the change as smooth as possible, but we welcome high quality bug reports to help us fix any problems that occur. Maven users will need to add a dependency on the new “leg-rc” package to access the old RC APIs.

There are some other changes that you might need to be aware of:

  • You’ll need to be running Java 8 to use the Java pieces of Selenium. This is the oldest version of Java officially supported by Oracle, so hopefully you’re using it already!
  • Support for Firefox is via Mozilla’s geckodriver.
  • Support for Safari is provided on macOS (Sierra or later) via Apple’s own safaridriver.
  • Support for Edge is provided by MS through their webdriver server.
  • Only versions 9 or above of IE are supported. Earlier versions may work, but are no longer supported as MS no longer supports them.

We’ll be posting more information about Selenium 3.0 to this blog soon, but until then if you’re interested in learning more then a recent webinar by Simon is a great place to start.


Categories: Open Source

Join me for Jenkins World 2016

Jenkins World, September 13-15 at the Santa Clara Convention Center (SCCC), takes our 6th annual community user conference to a whole new level. It will be one big party for everything Jenkins, from users to developers, from the community to vendors. There will be more of what people always loved in past user conferences, such as technical sessions from users and developers, the Ask the Experts booth and plugin development workshop, and even more has been added, such as Jenkins training pre-conference, workshops and the opportunity to get certified for free. Jenkins World is a not-to-be-missed. For me, the best part of Jenkins World is the opportunity to meet...
Categories: Open Source

Blue Ocean July development update

The team have been hard at work moving the needle forward on the Blue Ocean 1.0 features. Many of the features we have been working on have come a long way in the past few months but here’s a few highlights: Goodbye page refreshes, Hello Real Time updates! Building upon Tom's great work on Server Sent Events (SSE) both Cliff and Tom worked on making the all the screens in Blue Ocean update without manual refreshes. SSE is a great technology choice for new web apps as it only pushes out events to the client when things have changed on the server. That means there’s a lot less traffic going between your browser and...
Categories: Open Source

Sending Notifications in Pipeline

This is a guest post by Liam Newman, Technical Evangelist at Cloudbees. Rather than sitting and watching Jenkins for job status, I want Jenkins to send notifications when events occur. There are Jenkins plugins for Slack, HipChat, or even email among others. Note: Something is happening! I think we can all agree getting notified when events occur is preferable to having to constantly monitor them just in case. I’m going to continue from where I left off in my previous post with the hermann project. I added a Jenkins Pipeline with an HTML publisher for code coverage. This week, I’d like to make Jenkins to notify me when builds start and when...
Categories: Open Source

New packages for Jenkins 2.7.1

We created new native packages for Jenkins 2.7.1 today. These replace the existing packages. Due to a release process issue, the packaging (RPM, etc.) was created the same way as Jenkins 1.x LTS, resulting in problems starting Jenkins on some platforms: While we dropped support for AJP in Jenkins 2.0, some 1.x packages had it enabled by default, resulting in an exception during startup. These new packages for Jenkins 2.7.1, dated July 14, have the same scripts and parameters as Jenkins 2.x and should allow starting up Jenkins without problems. If you notice any further problems with the packaging, please report...
Categories: Open Source

Jenkins 2 hits LTS

It’s been almost three months since we’ve released Jenkins 2.0, the first ever major version upgrade for this 10 year old project. The 2.x versions since then has been adopted by more than 20% of the users, but one segment of users who haven’t seen the benefits of Jenkins 2 is those who has been running LTS releases. But that is no more! The new version of Jenkins LTS release we just released is 2.7.1, and now LTS users get to finally enjoy Jenkins 2. This release also officially marks the end-of-life for Jenkins 1.x. There won’t be any future release of...
Categories: Open Source

The Tweets You Missed in June

Sonar - Wed, 07/06/2016 - 09:52

Here are the tweets you likely missed last month!

SonarQube 5.6 LTS is available! Enjoy! https://t.co/NbrGmfjTuh https://t.co/1Qyh88kwtq pic.twitter.com/ZVoObqi2ub

— SonarQube (@SonarQube) June 8, 2016

Governance 1.0 gives a dedicated dashboard to get the big picture of application portfolios https://t.co/7uT4qnqi36 pic.twitter.com/XWkrNNcGBB

— SonarQube (@SonarQube) June 14, 2016

Issue found in #git source code by the C rule in charge to detect unconditionally true/false conditions pic.twitter.com/DvGPyiRE7N

— SonarQube (@SonarQube) June 15, 2016

Categories: Open Source

Publishing HTML Reports in Pipeline

This is a guest post by Liam Newman, Technical Evangelist at Cloudbees. Most projects need more that just JUnit result reporting. Rather than writing a custom plugin for each type of report, we can use the HTML Publisher Plugin. Let’s Make This Quick I’ve found a Ruby project, hermann, I’d like to build using Jenkins Pipeline. I’d also like to have the code coverage results published with each build job. I could write a plugin to publish this data, but I’m in a bit of hurry and the build already creates an HTML report file using SimpleCov when the unit tests run. Simple Build I’m going to use the HTML Publisher Plugin to...
Categories: Open Source

GSoC: External Workspace Manager Plugin alpha version

Currently it’s quite difficult to share and reuse the same workspace between multiple jobs and across nodes. There are some possible workarounds for achieving this, but each of them has its own drawback, e.g. stash/unstash pre-made artifacts, Copy Artifacts plugin or advanced job settings. A viable solution for this problem is the External Workspace Manager plugin, which facilitates workspace share and reuse across multiple Jenkins jobs and nodes. It also eliminates the need to copy, archive or move files. You can learn more about the design and goals of the External Workspace Manager project in this introductory blog post. I’d like to announce that an alpha version of...
Categories: Open Source

JavaScript Plugin Finds Tricky Bugs, Thanks to Execution Flow

Sonar - Wed, 06/29/2016 - 09:17

Over the last few months, the SonarAnalyzer for JavaScript has made major advances in bug detection. Until recently, it only caught rather simple bugs, like function calls passing extra arguments, which didn’t really need more than a correct identification of symbols. Things changed a lot when we made the analyzer aware of execution flow: in other words, it is now able to determine the precise order of execution inside a JavaScript function and detect bugs based on it.

The latest rule we implemented based on execution flow aims at no less than detecting when a property is accessed on a value which might be null or undefined. In such a case, a TypeError may be thrown at runtime, and the application may crash. That rule catches obvious bugs in poor quality code, but it can also find more subtle issues, such as when a value is sometimes tested for nullability and sometimes not. That’s the case in the following code in the React project:

Conditions which are either always true or always false represent another bug pattern for which we have a relatively new rule. Sometimes, such a condition is simply redundant with the rest of the code as in in the following example in the Closure Library:


(In JavaScript every value has an inherent boolean value and is therefore either “truthy” or “falsy”. False, null, undefined, NaN, 0, and the empty string are “falsy”. Everything else is “truthy”.)

In other cases, a condition which is always true or false may be the visible part of a real bug, especially when it means that a full block of code will never be executed. Here’s an example from the Ionic framework which looks like a serious bug:

Detecting dead stores is another rule we added recently and that is based on execution flow. A dead store is a useless assignment to a variable, where the variable that’s assigned is never read after the assignment. Most often, this is not a bug, just useless and potentially confusing code. However, it’s so common that thousands of dead stores can be found in open-source projects. Here’s a very simple example in the AngularJS project:

Now, we’ve said all of these rules are based on execution flow, but some curious readers may ask: how do we describe execution flow? Except in the simplest cases, execution flow is rarely linear. As soon as a piece of code contains an if statement, its execution flow has to be described with alternatives branches: either the condition of the if statement is true and we execute the associated block, or it’s false and we don’t execute the block. Moreover, execution flow may go back to a point which was already executed thanks to loops. In the end, in order to represent all the possible paths, we use a graph structure which is known as a control flow graph (CFG).

Based on a control flow graph, it’s rather easy to identify dead stores by checking all paths which come out of an assignment. However, a CFG is certainly not enough to detect potential TypeErrors or conditions which are always true or false. To do that, we need symbolic execution. That is, we need to track the values which are referenced by variables. We can walk through the CFG and evaluate some parts of the code:

  • Based on assignments, we may know the precise value of a variable at a given point.
  • Based on conditions in if statements or loops, we may know which constraints are met by the value of a variable inside a given block.

Running symbolic execution means that we explore the possible execution paths based on the CFG and the possible constraints on variables.

  • When looking for possible TypeErrors, we raise an issue as soon as one of the execution paths leads to a property access on a value which is constrained to null or undefined.
  • When looking for conditions which are always true or false, we have to check all of the execution paths which go through a condition.

Our symbolic execution engine is still in its early stages and can only evaluate simple constructs right now, but the current results of these new rules look very promising to us. As we improve our engine, the rules which are based on it will get more accurate. We’ve gotten this far by following the lead of the SonarAnalyzer for Java, which overshadowed FindBugs, turning it from a great tool to a great tool of the past. We hope we can bring as much value to JavaScript developers.

However, following Java’s lead is only part of the story. Because of the dynamic nature of JavaScript, symbolic execution is more crucial than for other languages like Java. For example, the type of a variable may not be the same for all branches of a given piece of code: many rules will therefore be improved as soon as we start to infer types based on symbolic execution. We have a lot to do, so stay tuned!

Categories: Open Source

Migrating from chained Freestyle jobs to Pipelines

This is a guest post by R. Tyler Croy, who is a long-time contributor to Jenkins and the primary contact for Jenkins project infrastructure. He is also a Jenkins Evangelist at CloudBees, Inc. For ages I have used the "Build After" feature in Jenkins to cobble together what one might refer to as a "pipeline" of sorts. The Jenkins project itself, a major consumer of Jenkins, has used these daisy-chained Freestyle jobs to drive a myriad of delivery pipelines in our infrastructure. One such "pipeline" helped drive the complex process of generating the pretty blue charts on stats.jenkins-ci.org. This statistics generation process primarily performs two major tasks, on rather large sets of...
Categories: Open Source

Fall Selenium Conf, Save the Date & Call for Speakers!

Selenium - Thu, 06/23/2016 - 14:09

We’re excited to announce that we’ve finally determined where and when Selenium Conf will be happening this Fall.

Our initial goal was to bring the event to a new country, but for a number of reasons that proved more challenging than we’d hoped. But in 2012 we had the 2nd annual Selenium Conf in London, and we’re pleased to be bringing it back there this year!

The conference will be held at The Mermaid in downtown London on November 14-16:

  • The 14th will be all-day pre-conference workshops
  • The 15th-16th will be the conference

Go here to sign up for the email list for conference updates (e.g., when tickets go on sale) as well as submit a talk. Call for speakers are open from now until July 29th.


Categories: Open Source

Language Plugins Rock SonarQube Life!

Sonar - Thu, 06/23/2016 - 13:43

SonarAnalyzers are fundamental pillars of our ecosystem. The language analyzers play a central role, but the value they bring isn’t always obvious. The aim of this post is to highlight the ins and outs of SonarAnalyzers.

The basics

The goal of the SonarAnalyzers (packaged either as SonarQube plugins or in SonarLint) is to raise issues on problems detected in source code written in a given programming language. The detection of issues relies on the static analysis of source code and the analyzer’s rule implementations. Each programming language requires a specific SonarAnalyzer implementation.

The analyzer


The SonarAnalyzer’s static analysis engine is at the core of source code interpretation. The scope of the analysis engine is quite large. It goes from basic syntax parsing to the advanced determination of the potential states of a piece of code. At minimum, it provides the bare features required for the analysis: basic recognition of the language’s syntax. The better the analyzer is, the more advanced it’s analysis can be, and the trickier the bugs it can find.

Driven by the will to perform more and more advanced analyses, the analyzers are continuously improved. New ambitions in terms of validation require constant efforts in the development of the SonarAnalyzers. In addition, to be able to handle updates to each programming language, regular updates are required in the analyzers to keep up with each language’s evolution.

The rules



The genesis of a rule starts with the writing of its specification. The specification of each rule is an important step. The description should be clear and unequivocal in order to be explicit about what issue is being detected. Not only must the description of the rule be clear and accurate, but code snippets must also be supplied to demonstrate both the bad practice and it’s fix. The specification is available from each issue raised by the rule to help users understand why the issue was raised.

Rules also have tags. The issues raised by a rule inherit the rule’s tags, so that both rules and issues are more searchable in SonarQube.

Once the specification of a rule is complete, next comes the implementation. Based on the capabilities offered by the analyzer, rule implementations detect increasingly tricky patterns of maintainability issues, bugs, and security vulnerabilities.


Continuous Improvement


By default, SonarQube ships with three SonarAnalyzers: Java, PHP, and JavaScript.
The analysis of other languages can be enabled by the installation of additional SonarAnalyzer plugins.

SonarQube community officially supports 24 language analyzers. Currently about 3500 rules are implemented across all SonarAnalyzers.

More than half of SonarSource developers work on SonarAnalyzers. Thanks to the efforts of our SonarAnalyzer developers, there are new SonarAnalyzer versions nearly every week.

A particular focus is currently made on Java, JavaScript, C#, and C/C++ plugins. The target is to deliver a new version of each one every month, and each delivery embeds new rules.

In 2015, we delivered a total of 61 new SonarAnalyser releases, and so far this year, another 30 versions have been released.


What it means for you


You can easily benefit from the regular delivery of SonarAnalyzers. At each release, analyzer enhancements and new rules are provided. But, you don’t need to upgrade SonarQube to upgrade your analysis; as a rule, new releases of each analyzers are compatible with the latest LTS.

When you update a SonarAnalyzer, the static analysis engine is replaced and new rules are made available. But at this step, you’re not yet benefiting from those new rules. During the update of your SonarAnalyzer, the quality profile remains unchanged. The rules executed during the analysis are the same ones you previously configured in your quality profile.
It means that if you want to benefit from new rules you must update your quality profile to add them.

Categories: Open Source

GSoC: Mid-term presentations by students on June 23 and 24

As you probably know, on this year Jenkins projects participates in Google Summer of Code 2016. You can find more information about the accepted projects on the GSoC subproject page and in the Jenkins Developer mailing list. On this week GSoC students are going to present their projects as a part of mid-term evaluation, which covers one month of community bonding and one month of coding. We would like to invite Jenkins developers to attend these meetings. There are two additional months of coding ahead for successful students, so any feedback from Jenkins contributors and users will be appreciated. Meeting #1 - June 23, 7:00 PM UTC -...
Categories: Open Source

Faster Pipelines with the Parallel Test Executor Plugin

This is a guest post by Liam Newman, Technical Evangelist at Cloudbees. In this blog post, I’ll show you how to speed up your pipeline by using the Parallel Test Executor Plugin. So much to do, so little time…​ Every time I’ve moved a team to continuous integration and delivery, one problem we always encounter is how to run all the tests needed to ensure high-quality changes while still keeping pipeline times reasonable and changes flowing smoothly. More tests mean greater confidence, but also longer wait times. Build systems may or may not support running tests in parallel but only on one machine even while other lab machines sit idle....
Categories: Open Source

Jenkins Pipeline Scalability in the Enterprise

This is a guest post by Damien Coraboeuf, Jenkins project contributor and Continuous Delivery consultant. Implementing a CI/CD solution based on Jenkins has become very easy. Dealing with hundreds of jobs? Not so much. Having to scale to thousands of jobs? Now this is a real challenge. This is the story of a journey to get out of the jungle of jobs…​ Start of the journey At the beginning of the journey there were several projects using roughly the same technologies. Those projects had several branches, for maintenance of releases, for new features. In turn, each of those branches had to be carefully built, deployed on different platforms and versions, promoted...
Categories: Open Source

Sonar ecosystem upgrades to Java 8

Sonar - Tue, 06/14/2016 - 17:55

With the release of SonarQube version 5.6, the entire Sonar ecosystem will drop support for Java 7. This means you won’t be able to run new versions of the SonarQube server, execute an analysis, or use SonarLint with a JVM < 8.

Why? Well, its been over two years since Java 8′s initial release, and a year since Oracle stopped supporting Java 7, so we figured it was time for us to stop to. Doing so allows us to simplify our development processes and begin using the spiffy new features in Java 8. Plus, performance is up to 20% better with Java 8!

Of course, we’ll still support running older versions of ecosystem products, e.g. SonarQube 4.5, with Java 7, and you’ll still be able to compile your project with a lower version of Java. You’ll just have to bump up the JVM version to run the analysis.

Categories: Open Source

Jenkins World Agenda is Live!

Join us in Santa Clara, California on September 13-15, 2016! We are excited to announce the Jenkins World agenda is now live. There will be 50+ sessions, keynotes, training, certifications and workshops. Here are a few highlights of what you can expect: High level topics Continuous delivery DevOps Microservices architectures Testing Automation tools Plugin development Pipeline Best practices And much more Additionally, Jenkins World offers great opportunities for hands-on learning, exploring and networking: Plugin Development Workshop Due to its popularity in previous years, we are bringing back the plugin development workshop. This workshop will introduce developers to the Jenkins plugin ecosystem and terminology. The goal is to provide a cursory overview of the resources available to Jenkins plugin developers. Armed...
Categories: Open Source

GSoC Project Intro: Support Core Plugin Improvements

About me I am Minudika Malshan, an undergraduate student in Computer Science and Engineering from University of Moratuwa, Sri Lanka. As a person who is passionate in open source software development and seeking for new knowledge and experience, I am willing to give my contribution for this project. LinkedIn | Twitter Abstract The Support-Core Plugin provides the basic infrastructure for generating "bundles" of support information with Jenkins. There are two kinds of bundles. Automatic bundles: Bundles which are generated and get saved in $JENKINS_HOME/support once per hour starting 15 seconds after Jenkins starts the plugin. The automatic bundles are retained using an exponential aging strategy. Therefore it’s possible...
Categories: Open Source

Upcoming June Jenkins Events

It is hard to believe that the first half of 2016 is almost over and summer is just around the corner. As usual, there are plenty of educational Jenkins events planned for this month. Below lists what’s happening in your neck of the woods: Online JAM June 14: Plugin Development - Basics North America JAMs June 14: Pipeline in a Windows Environment - Boston, Massachusetts June 15: Open Source Jenkins 2.0, What’s New? - Washington, DC June 22: Continuously Deploying Containers with Jenkins Pipeline to a Docker Swarm Cluster - Seattle, Washington Europe JAM June 14: Jenkins 2.0 - London, United Kingdom June 22: Pipeline As Code - Toulouse, France Links Start a...
Categories: Open Source