One of the concerns people may have when they start using Wercker for Continuous Integration is whether other people can see or access their source code. In this article we will look at some of the authorization aspects of Wercker and at the technology behind Wercker.
Before describing in detail what is visible to whom, let’s take a look first at how to prevent sensitive information from being accessible to the wrong people via Wercker. There are four main areas where sensitive information may be visible:
Wercker provides no access to the source code of an application. Your source code is handled by specific testing servers, which clone your code and run your tests in separate containers which are setup and destroyed for each build. The resulting build artefacts are stored and accessible only for Wercker servers up to 3 months for use during deployment.
Maybe your code contains that default password you should change, or there’s other information you don’t want to have in your test logs. Wercker offers some tools to help you: you can hide the output of commands by setting the log value to false. See the wercker.yml article for more details.
Since Wercker allows you to set environment variables for configuring deploy-specific information, there’s a chance sensitive information can end up in the deploy log. To prevent this from happening, we’ve added a “hidden from log” checkbox for each environment variable that you define.
Deploy settings are the most specific details of your deployment. Only people with sufficient permissions can access these on an application. Specifically, only users with write permissions or admin rol es have access. The difference between these roles will be described later.
This section applies only if your application is in a GitHub repository.
If your repository is public, anyone can create a fork of your repository and create a pull request to merge a branch from their repository into a branch in your repository.
You can configure whether or not such pull requests should trigger runs in Wercker.
If you specify that pull requests from forked repositories should trigger runs in Wercker you can can also specify whether or not those runs should have access to any “secrets” (environment variables that you have marked as protected) that you have defined in your application.
Please see Oracle’s security vulnerability reporting policy for information about security vulnerabilities.