Bitbucket Cloud Repository Detection with CloudBees Jenkins Workflow

One the most important concepts introduced this year in the Jenkins ecosystem was the idea of storing your continuous delivery pipeline as code . Jenkins Workflow can not only allow you to define and visualize your entire pipeline in one job, but now that pipeline can be stored and versioned along with your application’s source code within your SCM as described here . This allows your pipeline to evolve and change as your application matures and increases in complexity. When your pipeline is stored in the application’s SCM as a Jenkinsfile , Multibranch Workflow projects will create Jenkins jobs for each branch in the given repository that contains a Jenkinsfile. In turn, as a new branch is created for your application, Jenkins will detect the new branch and create a new job from the CD pipeline defined in the Jenkinsfile, all with its own build history.

Typically, an organization using Git today will have many different Git repositories defined, especially if an application is comprised of many deployable artifacts, as is the case when using a microservices architecture pattern. Because of the amount of repositories and branches, configuration and maintenance of Jenkins projects for these applications can take up a lot of admin time. With the release of Cloudbees Jenkins Platform 15.11, Jenkins has the ability to create and manage workflow jobs for all repositories within Github, Github Enterprise, or Bitbucket Cloud. At this level, the only information that needs to be given to Jenkins is the organization name and credentials. Jenkins will then create Folders for each repository and projects for each branch that contains a Jenkinsfile. When the branch has been merged back into controller and deleted, the project will be removed from Jenkins as well.

• Cloudbees Jenkins Platform

  • Cloudbees Workflow: Aggregator (1.6+)

  • Workflow Plugin (1.11+)​

  • Cloudbees Bitbucket Cloud Branch Source Plugin (1.0+)

In Cloudbees Jenkins Enterprise, click New Item -> Bitbucket Team . In the Repository Sources section of the configuration enter the Bitbucket Team Owner as well as the Scan Credentials required to access the BitbucketTeam. You can use a BitbucketTeam API Key for the Scan Credentials, by navigating to the Bitbucket Cloud UI and going to the Team Settings -> API Key (Under Access Management section). You can then use the generated API Key displayed as the password and the team name as the username.

After the Team Owner and Scan credentials are entered into the Bitbucket Team project, having the Auto-register webhooks checkbox checked will allow Jenkins to create the webhooks in Bitbucket for the repositories that it detects. This allows any commits or Pull Requests to trigger a new build within Jenkins. In order for Jenkins to detect new repositories in Bitbucket and subsequently set up the webhook for the first time, Jenkins needs to poll Bitbucket at a given interval. By default, Jenkins will poll Bitbucket once a day for any new repositories to set up the webhooks. This can be modified by changing the value in the Periodically if not otherwise option in the Build Triggers section. After clicking Save , Jenkins will scan for any repositories and create Folders for each repository. Jenkins will then create new Jenkins projects within the repository folder for each branch that contains a Jenkinsfile. Note that repository folders will only be created if at least one branch contains a Jenkinsfile. Each branch will have its own workspace, history, and CD Pipeline Stage View associated with it.

Now that the setup has been complete, when a new commit or branch is created within the repository, Jenkins will trigger a build or create a new branch project, respectively.

Many Bitbucket users employ the pull-request mechanism in order to review code before changes are adopted and merged into the mainstream development branch. This tends to be very convenient because Bitbucket has a nice UI to discuss potential changes and review the differences between branches. Even with manual code reviews, not all mistakes can be found before accepting a pull request in this manner. Additionally, a lot of time can be wasted reviewing a pull-request only to find out afterwards that the tests failed in the build stage after merging. With Cloudbees Jenkins Workflow, Jenkins will create a new CD pipeline when a pull-request is submitted and build/test the pull-request. Once this has occurred, a comment will be added by Jenkins to the commit in Bitbucket with the status of whether the tests passed or failed as well as a link back to the Workflow Job. This comment certifies that the pull-request you are reviewing has been tested and would not break the build if merged. With Bitbucket Organization Folders this is automatically enabled, so there is no configuration necessary.

The introduction of pipeline as code has significantly changed the way pipelines can be created within Cloudbees Jenkins Platform. With the ability to specify a Jenkinsfile as part of your application source code, there is no longer the need to create new projects for every application and branch -- Jenkins will do this for you. This reduction in maintenance coupled with fact that every Pull Request can first be tested within Cloudbees Jenkins Platform creates a transparent and consistent software pipeline thus allowing companies to deliver better software faster.

Isaac Cohen is a Solutions Architect at CloudBees , enabling customers to achieve their DevOps \ Continuous Delivery goals and making the overall SDLC as efficient and transparent as possible. Isaac has extensive knowledge of Jenkins and its various tool integrations as well as hands-on experience leading DevOps teams for large enterprises.