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.
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 http://discuss.bitrise.io/ , in the Step Dev category. http://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 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!
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 http://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.
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.
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
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
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.)
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
I’ll try to create the org today, hopefully I’ll (finally) have the time to do that…
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.
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.
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.
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.
