Bitrise steps community

step

#1

There are many steps available and Bitrise and it’s awesome. I made some for things such as :

  • Posting build details on JIRA
  • Sending build on Appetize
  • Create QR code for the build download page URL

I thing the Bitrise community would benefit having a community organisation where the community could improve all steps in a unique place. Here are the pros :

  • A place where it’s easy to share steps development knowledge
  • A common standard for great quality steps
  • A fastest release cycle (no single reviewer bottleneck)

I just wanted to open the discussion and looking forward to see if people are interested in this.


Report an Abandoned Step
#2

We’re definitely interested in something like this, but a couple of things are not clear yet.

We’re still discussing what the right platform for this collaboration would be, our current thought is that it should be here, on https://discuss.bitrise.io/ , in the #dev:step-dev category. https://discuss.bitrise.io/ is still quite new, so this is still an “experiment”, but if anyone have any feedback we’re always happy to discuss possible changes/improvements, not just for coding/specs but also for communication.

We think that we still have to improve our docs and our tooling around step dev, hopefully that and #dev:step-dev should make this happen (easy to get started and to write great quality steps).

Definitely! Tooling will help in the future (we plan to add a step dev core plugin to the Bitrise CLI, so that you’ll be able to create a new step with just bitrise step create .., for example), as well as tools like releaseman, but as most of these things are still work-in-progress we’re not happy with the current state. We started to expand the tooling team, so hopefully we can work on these more in the near future.

We also have other ideas for faster step release cycle, like identifying step repositories on bitrise.io when you register one and auto generating a suitable base workflow for them, just like for iOS/Android/Xamarin/Mac/… apps.

Thank you! We definitely have to improve things, and community feedback would help us a lot, so keep the ideas & questions coming! :wink:

We’re also trying to be more open regarding our development processes and about what we work on, e.g. by sharing more and more things in #changelog and here on https://discuss.bitrise.io/ in general.

Our goal is to make it possible for anyone who want to get involved with any part of bitrise to be able to do so quickly and easily, be it a step contribution, guides / #how-to , or just discussing possible improvements or highlighting pain points which could be solved better (e.g. Support for multiple apk in android workflows ).

As always, any feedback is much appreciated and helps us a lot to see how others use bitrise and how we could make it better.


#3

This board is great for more free-form discussion. A StackOverflow-style site might be better for bubbling up the best technical Q&A responses and letting the community keep them up to date (here are some options for hosting that type of Q&A). In fact, Jeff Atwood has a great blog post where he talked about why they designed Discourse (the platform this board is running on) for stuff other than Q&A. And Github is more appropriate for collaborating on codebases.

I do like the idea of having a Github organization for community-maintained steps. We could still have individually owned steps, but would be nice if there were a process (maybe voting?) for forking abandoned or poorly maintained steps into the community organization. We should be careful to have a way to establish trust in a group of maintainers here: those in good standing in the community with a track record of maintaining their own steps with high code quality and being responsive to PRs. I think you can even set up different github ACLs so that some members could do advisory PR reviews but only some people would have permission to merge to master. Code review is a great way to foster quality and build consensus on best practices.

I’d consider volunteering as a member of a community maintenance group.


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


#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.)


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


#7

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


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


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


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


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


#12

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


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


#14

Great !
My GitHub nick is “dagio”.


#15

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


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


#17

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


#18

@viktorbenei https://github.com/fadookie


#19

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


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