You will need roughly 6 minutes to read this article.
Let’s take a look at how Codeship manages permissions around your source control, your builds and your team.
When we say permissions, we are talking about access you give Codeship to your source control repo, or access you give to people on your team to your Codeship builds and account information.
In terms of access you give Codeship, there are two different types that are in play: repository level permissions and access level permissions.
For Codeship to configure your repo correctly, the account that connects a repo needs to have the necessary permissions to setup a webhook etc on the repository. For this, we expect that account to have
admin permissions (or master or owner depending on your source control system).
As for access permissions, these influence what we’re allowed to do on your behalf, on a per-build basis. We need access to clone your repo, as well as report back with the test results, but not full admin permissions.
The next section explains which specific permissions we ask for, depending on your source control system.
As mentioned above, Codeship requires both repository and access level permissions. Depending on the source control service being used, these are called something different:
user:emailscopes). We are looking to move to the new GitHub Integration options, to offer you more granular control, in the near future.
webhook. You can see the full list of permission options available from BitBucket here.
apiscope), which unfortunately gives us access to everything on the repo. We wish it was different, but as of now, GitLab only provides two options where only one will allow us to access your repos.
You can learn more about organization management on Codeship by clicking here, but in general there are four basic security levels for teams on Codeship:
Owners have control over all aspects of an organization. From changing the subscription to managing organization projects and teams.
Managers have control over team and project management of an organization. They can add and remove projects and manage the organization teams by adding new team members or assigning projects to teams. They have access to all projects and are able to change the project configuration.
Project Managers can manage projects the team is assigned to. They can debug builds, update test settings, or manage deployments.
Contributors have read-only access to their projects. This means that they can view the project dashboard and build details but are not allowed to change project settings or open debug builds.
Note this only applies to Github.
If the repositories for a GitHub organization don’t show up on Codeship, please head over to the settings for the Codeship application on GitHub and in the section labeled Organization access either
Once this is done and access has been granted, the organizations repositories will show up in the repository selector on Codeship again.
See GitHub’s help article on 3rd party restrictions for more background information about this feature.
If you attempt to connect a repository to a new project, and you don’t have
admin permissions on that repository, there are two things you can do:
adminpermissions to the repo, which can be given to the team you’re in or specifically to your user
adminpermissions, setup the project for you. The flow would look like this:
adminpermission creates the project and connects the repo (Codeship will create a webhook and register an SSH key)
You can learn more about security on Codeship by clicking here.
There are two Codeship services, and staff have different levels of access for each:
On Codeship Basic, with your permission, our support team can open an SSH debug session into your build machine, which allows us to see your source code.
On Codeship Pro, we have no direct access to your source control, but our support team can see your builds and build logs, as well as account information.
Do you think we need to improve this article? If so, please submit our feedback form to help us improve this article!