Bitrise steps community

step

#21

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:


#22

We might have a use for the Organization real soon:


#23

Checklist for adding a new Repo to the Community

  • [ ] Add/Transfer the Repository into the https://github.com/bitrise-community 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 bitrise.io:
    • [ ] Add the Repo, into the Bitrise Community organization
    • [ ] Open the App on Bitrise.io, go to Team tab and make sure the Maintainers (admins) group is added with Admin permissions
    • [ ] Open the App on Bitrise.io, 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 bitrise.io app: make sure that the REPOSITORY URL on the Settings tab (on bitrise.io) 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 Bitrise.io
  • [ ] 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 bitrise.io, something like:

trigger_map:
- 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 bitrise.io config for these repos:

---
format_version: '3'
default_step_lib_source: https://github.com/bitrise-io/bitrise-steplib.git
project_type: other
trigger_map:
- push_branch: master
  workflow: test
- pull_request_source_branch: "*"
  workflow: test
workflows:
  test:
    steps:
    - git-clone: {}
    - script:
        title: bitrise run test
        inputs:
        - content: |-
            #!/bin/bash
            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


#24

#25

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


#26

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


#27

yep i’m in thanks :smile: