Bitrise steps community

step
#4

I agree, I’m just not sure about a couple of details - but we’re discussing it internally as well as sharing our notes here :wink:

That’s an excellent point, I’d be motivated to create a github organization just for this single reason actually!

That’s exactly one of our main concern and discussion topic internally, how we could protect these steps to be deleted or “destroyed” completely by someone who has access to the GH organization, e.g. by force git push-ing into every step. We trust our community, but life experience is that even the most humble/brilliant people can sometimes get angry/exhaused and/or do irrational things. We have to be sure to minimize the chance of letting someone destroy other people’s work.

I’ll have to check this, or if anyone has any experience with a GitHub permission setup like this, please let us know!

Awesome point again, I’d definitely be happy to do code review for others’ steps or ask for a review from someone else!

You’ll be the first one if/when we create a GH organization :wink:

1 Like

#5

I’ll have to check this, or if anyone has any experience with a GitHub permission setup like this, please let us know!

I think the first step would be to create two teams: one for maintainers and one for regular reviewers. Both should be given write access to the repo.

Then, enable branch restrictions so that only maintainers can push to the master branch.

Finally, enable required reviews for the master branch. Anybody with write access should then be able to submit a review, but I think only maintainers will be allowed to merge.

Also, protected branches cannot be force-pushed or deleted (unless an admin temporarily disables branch protection.) So maintainers should probably not be admins unless you trust them quite a bit. (More info about team permissions is here.)

There’s also a great opportunity here to dogfood some of the bitrise github/PR integration by having a CI job for each step repo and making it a required status check. It can run the audit-this-step and test workflows for each commit so that PRs will be blocked until the tests exist and are passing. (Will have to put some thought into how a test environment can be made for each step without bloating the step repo size.)

0 Likes

#6

Perfect! We were thinking about a setup like this, but you summarized it perfectly!

I’ll go ahead and create an organization with this setup, as well as publish a guide here, summarizing all the required and best-practice steps.

Do you have a suggestion for the organization’s name @eliot_pear? Maybe bitrise-community-steplib? Or just bitrise-community?

1 Like

#7

I like bitrise-community as that makes it more open for collaborating on toolchain/infrastructure stuff as well instead of just steps.

1 Like

#8

bitrise-community is great. I have a tool to generate dynamically workflows that might fit there. It’s not a step.

If you need help, I’d be happy to help.

2 Likes

#9

Wow, that sounds awesome! It’s not a secret that one of our goal with the open bitrise.yml specs and with the CLI is to provide a way for others as well to build tools around the build config (e.g. the new open source & offline Workflow Editor) and the runner. If you’d have any missing feature, or docs, please let us know!

I agree, it makes sense, although maybe not “playful” enough, but the name of the Organization can be changed later, that’s always an option :wink:

I’ll try to create the org today, hopefully I’ll (finally) have the time to do that…

0 Likes

#10

Awesome!

I think changing the name will break clone URLs on any repos so we should probably pick a name we like before pointing anything to repos in the organization.

0 Likes

#11

If we can we definitely should, but in case of GitHub, we never had any issues with renaming a repo or transferring it; I believe GH can handle Organization renames quite well too. The only issue we had with renames is pushing back build/CI status for pull request tests, there you have to address the repo with the up to date name/URL, but git clone etc. work just fine after a rename or transfer.

0 Likes

#12

That said, I’m quite happy with bitrise-community, unless we can find a better name this should work IMO

0 Likes

#13

Btw I just created the bitrise-community organization on GitHub, with a Maintainers and Contributors teams (following Bitrise steps community). Everyone in the Org have Write access automatically, maintainers will also have Admin.

If you want to join, just let me know @dag-io @eliot_pear, which github account you want me to add (if you have more than one); I’ll try to work on this more in the coming days. Feedback is also much appreciated.

0 Likes

#14

Great !
My GitHub nick is “dagio”.

1 Like

#15

Added to the https://github.com/bitrise-community org, and to the “Collaborators” team.

0 Likes

#16

In the meantime I’ll create an Organization on Bitrise.io too and invite you into that.

@eliot_pear what’s your GitHub user?

0 Likes

#17

@dag-io I also invited you to the “Bitrise Community” bitrise.io Organization :wink:

0 Likes

#18

@viktorbenei https://github.com/fadookie

1 Like

#19

@eliot_pear invited you to both the GitHub and the Bitrise orgs :wink:

0 Likes

#20

Awesome, thanks!

I made a test project in the github org as it might be a good way to do high-level project organization. Looks like it’s basically a trello board but you can easily make issues and PRs into cards.

1 Like

#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:

0 Likes

#22

We might have a use for the Organization real soon:

1 Like

#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

2 Likes