Bitrise steps community



Awesome, great idea @eliot_pear!

We experimented a bit with GH projects back when they announced it, our main issues were:

  1. no cross Organization support (we have quite a few)
  2. no automatic add to “Backlog”, which means that you have to add every PR/issue manually to the project/board

I’m sure these will be solved, and in this case the first point doesn’t even apply, so let’s see how this goes! :wink:


We might have a use for the Organization real soon:


Checklist for adding a new Repo to the Community

  • [ ] Add/Transfer the Repository into the GitHub organization
  • Settings -> Options:
    • [ ] Merge button -> only allow Allow squash merging
  • Setting -> enable Issues (it’s disabled by default for forks)
  • Settings -> Branches:
    • [ ] Add a protected branch for master
    • [ ] Enable every protection option there
  • Settings -> Collaborators & teams:
    • [ ] Add the Maintainers (admins) team with Admin permissions
    • [ ] Add the Collaborators team with Write permissions
  • On
    • [ ] Add the Repo, into the Bitrise Community organization
    • [ ] Open the App on, go to Team tab and make sure the Maintainers (admins) group is added with Admin permissions
    • [ ] Open the App on, go to Team tab and make sure the Collaborators group is added with Developer permissions
    • [ ] Set the Service credential User to viktorbenei (should we change this to a “bot” user?)
    • [ ] Click the “Test git connection” button to test the Service credential User and make sure it’s green!
    • [ ] If you transferred an existing repo and app: make sure that the REPOSITORY URL on the Settings tab (on has the up to date git clone URL!
  • [ ] Create a quick PR on GitHub (e.g. just edit the README)
  • [ ] Wait for the build status to be reported on GitHub by
  • [ ] Once the PR status is reported, make it a required check on GitHub (Settings -> Branches -> master -> Require status checks to pass before merging -> mark the /pr status to be required)
  • [ ] Close the test PR and delete the related branch too

It’s also a good idea to have a “PR only” trigger map configured for the project on, something like:

- push_branch: master
  workflow: primary
- pull_request_source_branch: "*"
  workflow: primary

This will prevent double builds for PRs coming from the same repo.

Use this config for these repos:

format_version: '3'
project_type: other
- push_branch: master
  workflow: test
- pull_request_source_branch: "*"
  workflow: test
    - git-clone: {}
    - script:
        title: bitrise run test
        - content: |-
            set -ex

            bitrise run test
    - deploy-to-bitrise-io: {}

This will simply clone the repo and then run the test workflow from the repo.

Checklist for adding a new User/Member to the Community



@viktorbenei can you invite me to the bitrise community organisation - my username is nhammond :slight_smile:


@nhammond invitation sent. from now you should be able to visit the builds, which belongs to the bitrise community organisation (like ionic-archive ci)


yep i’m in thanks :smile: