The mobile developer community has made Bitrise what it is today. We're eager to support you as you help us further improve the world's most popular mobile app development platform. - bitrise.io
If you wish to contribute to Bitrise, or take part in the community discussions, we have some links for you:
- Edit existing articles or submit new ones to our docs.
- Read our blog, and contact us if you whish to write your own blog post.
- Request a feature, submit an issue, or just talk to other members of our community on our forums.
You can find out more on contributions on Devcenter.
Fixing a simple bug is a great way to start contributing your code to Bitrise. If you found a bug that you would like to fix, please follow this process:
- Check if there is an existing GitHub issue about the problem, if not, create one.
- Read the Coding Guideline.
- Open a Pull Request.
You can also check for open Github issues and discuss for open bugs that you can contribute to.
🚧 Currently under construction and will be updated in the future.
We have always been grateful for community contributions that enhance our Steps. Currently we are working on providing a better environment for your features to be added. We will update our Contribution Guide once we are ready to accept your ideas again.
In the meantime, please feel free to share your feature ideas on Discuss.
This section helps you get started making changes to an existing Bitrise Step.
Each Step has its own GitHub repository that includes code and the step.yml file that defines the configuration of the Step.
Most of the official Bitrise steps are written in Go, a simple and efficient programming language. If you are new to the language, we recommend playing with A Tour of Go and Go by Example.
To get started, let's set up your local environment:
- Install Go
- Install Bitrise CLI - or if it's already installed, make sure it's up to date by running
bitrise updateandbitrise plugin update - Fork and
git clonethe step repo you want to make changes to
A typical Bitrise step folder structure looks like this:
├── README.md
├── bitrise.yml # Workflows for checking code quality and running tests
├── e2e
│ └── bitrise.yml # Workflows that run end-to-end tests on the step
├── go.mod # Go module dependencies
├── go.sum # Dependency checksums
├── main.go # Main entry point of step, execution starts here
├── main_test.go # Tests
├── step.yml # Metadata describing the step (input, outputs, description)
├── vendor/ # Vendored dependencies
Bitrise is built on Bitrise, so the Steps are tested using CI workflows defined in bitrise.yml and e2e/bitrise.yml. While making changes to a step, you can run these workflows locally using the Bitrise CLI.
In the root bitrise.yml the check workflow lints your code and runs Go tests (e.g. main_test.go). End-to-end test workflows are defined in e2e/bitrise.yml and you can run a single test workflow by bitrise run workflow_name --config e2e/bitrise.yml. These tests run the whole step as part of a larger workflow using a sample mobile project and test the functionality end-to-end.
These test workflows are run automatically on Bitrise when a new PR is opened and the build is approved by the maintainers. This Bitrise project is private at the moment, so you can't see the results if the build failed. Don't worry, once you open a PR, we'll help you fix any failing test.
If you want to test your modified Step in your own real project, you can change the workflow to run your forked version of the step:
steps:
- git-clone@6: #replace this
- git::https://github.com/username/steps-git-clone@branchname: # with this 🚧 Currently under construction and will be updated in the future. The guide is only applicable for Go based Steps. Please follow to conventions of the existing code for Ruby and Bash based Steps.
This section is intended to describe the coding conventions applied for the Step. Please refer to it when contributing code to the repository.
Our single guide currently is to apply Effective Go, which has a great number of tips on writing clear and idiomatic Go.
We also have a collection of Step-specific guidelines and best practices.
Please refer to our issue template picker if something is not behaving as expected while using the Step. The template picker guides you to the appropriate forum where you can ask your question and we can quickly assist you.
Please note that Github issues not comforming to the bug template will be closed and asked to be reopened.