Make sure you have bundler
installed using gem install bundler
- Open the GitHub page of the
fastlane
repository (e.g. https://github.com/fastlane/fastlane) - Create an issue to discuss your idea/feature/enhancement.
- Click on
Fork
on the top right - Then clone your new repo locally
git clone https://github.com/[my_user]/fastlane.git
- On your terminal, navigate to the project and run
git remote add upstream https://github.com/fastlane/fastlane
(or use thegit
URL if you use private key auth) - Create your feature branch (
git checkout -b my-new-feature
). - Commit your changes (
git commit -am 'Add some feature'
). - Push to the branch (
git push origin my-new-feature
). - Create a new Pull Request.
Before working on something, make sure to have pulled the latest changes. To pull the changes run
git pull master
To submit the changes to the fastlane main repo, you have to do the following:
- Squash your commits into one. For example, to squash three commits into one, do the following:
$ git rebase -i HEAD~3
. In the text editor that comes up, replace the words "pick" with "squash" next to the commits you want to squash. Save and close the editor. For more information, take a look at 7.6 Git Tools - Rewriting History - Run
git push upstream master
. If you pushed before squashing, go back and do the previous step, and then rungit push upstream master --force
- Open
https://github.com/fastlane/fastlane
in your browser and click the green "Create Pull Request" button
Before submitting a new issue, do the following:
- Verify you're running the latest version by running
fastlane -v
and compare it with the project page on GitHub. - Verify you have Xcode tools installed by running
xcode-select --install
. - Make sure to read through the README of the project.
When submitting a new issue, please provide the following information:
- The full stack trace and output when running
fastlane
. - The command and parameters you used to launch it.
- Your
Fastfile
and all other configuration files you are using.
By providing this information it's much faster and easier to help you
If you're motivated to help out at a level beyond reporting issues, we really appreciate it! 👍 A good place to start is by reviewing the list of open issues or open PRs for things that need attention. When you find one that you'd like to help with, the countdown repo is the best way to get set up with the source code for all of the fastlane projects. With that, working on the following things are super valuable:
Are you able to reproduce this problem on your computer? If so, chime in! If the original issue report is a bit vague, but you have some additional details, please contribute them! If you find a bug report without an example script or configuration, contribute one that can be used to reproduce it.
If you're comfortable diving into the code a bit, see if you can produce a failing test that illustrates the bad behavior in the problematic area of the code! Tests live in the spec/
directory, and are generally named relative to the source code files whose functionality they test. Once you are done, git diff > my_patch.diff
can be used to produce a patch file containing the details of your changes, which can be added to the issue.
Another way to help out is to verify submitted pull requests. To do that, you'll need to be able to get the author's proposed changes onto your machine. Start by giving yourself a new branch to work in:
git checkout -b testing_branch
Next, you'll need to tell git where to find this contributor's fastlane fork and branch. Let's say that the contributor's username is JohnSmith and their topic branch is called new_fastlane_action
located at https://github.com/JohnSmith/fastlane. You can use the following commands to pull their work:
git remote add JohnSmith https://github.com/JohnSmith/fastlane.git
git pull JohnSmith new_fastlane_action
Once you have their changes locally, there's many things worth checking on:
- Does the change work?
- Are there adequate tests to cover the changes or new functionality? Are the tests clear and testing the right things?
- Is the related documentation updated? New actions get described in
docs/Actions.md
, for example. - How does the code look to you? Can you think of a nicer or more performant way to implement part of it?
If you're happy with what you see, leave a comment on the GitHub issue stating your approval. If not, leave a polite suggestion for what you think could be improved and how. The more you can show that you've reviewed the content seriously, the more valuable it will be to the author and other reviewers!
Pull requests are always welcome :simple_smile:
If you're working on fixing a particular issue, referring to it in the description of your PR is really helpful for establishing the context needed for review.
If your PR is contributing new functionality, did you create an issue to discuss it with the community first? Great! 🙌 Reference that issue in your PR.
Pro tip: GitHub will automatically turn references to issue numbers in the form #1234
into a link to the issue/PR with that number within the same repo.
- Adding automated tests that cover your changes and/or new functionality is important!
fastlane
has a lot of moving parts and receives contributions from many developers. The best way to ensure that your contributions keep working is to ensure that there will be failing tests if something accidentally gets broken.- You can run the tests by executing
bundle install
and thenbundle exec rspec
.
- Your code editor should indent using spaces with a tab size of 2 spaces.
It's not you, it's us! fastlane and its related tools receive a lot of issues and PRs. In order to effectively work through them and give each the prompt attention it deserves, we need to keep a sharp focus on the work we have outstanding.
One way we do this is by closing issues that we don't feel are immediately actionable. This might mean that we need more information in order to investigate (Have you provided enough information for us to reproduce the problem? The New Issues section has the details!). Or, it might mean that we haven't been able to reproduce it using the provided info. In this case we might close the issue while we wait for others to reproduce the problem and possibly provide some more info that unlocks the mystery.
In any case, a closed issue is not necessarily the end of the story! If more info becomes available after an issue is closed, it can be reopened for further consideration.
One of the best ways we can keep fastlane an approachable, stable, and dependable tool is to be deliberate about how we choose to modify it. If we don't adopt your changes or new feature into fastlane, that doesn't mean it was bad work! It may be that the fastlane philosophy about how to accomplish a particular task doesn't align well with your approach. The best way to make sure that your time is well spent in contributing to fastlane is to start your work on a modification or new feature by opening an issue to discuss the problem or shortcoming with the community. The fastlane maintainers will do our best to give early feedback about whether a particular goal and approach is likely to be something we want to adopt!
Writing a custom action is an easy way to extend the capabilities of fastlane. Actions that make good candidates for inclusion in the fastlane codebase are flexible and apply to many projects, teams, and development setups. Before working to contribute your custom action to fastlane, consider whether it is likely to solve a problem that many developers have. If not, it can still provide value for your fastlane environment! Check out the documentation for creating local action extensions.
When working on something, directly edit the Ruby files in the project folders. Make sure to switch your text editor to use spaces and indentations should be 2 spaces.
To run the modified version of the tool, run the following in the project directory
./bin/[tool_name]
or install the local copy (might require sudo
)
bundle install && rake install
I personally use a plain Sublime Text with a terminal. Debugging is pretty easy, just insert the following code to where you want to jump in:
require 'pry'
binding.pry
You then jump into an interactive debugger that allows you to print out variables, call methods and much more. Continue running the original script using control
+ d
You'll see some old code still using puts
or Helper.log.info
to print out values. From now, please only use the new UI
class to interact with the user (both input and output)
UI.message "Neutral message (usually white)"
UI.success "Succesully finished processing (usually green)"
UI.error "Wahaha, what's going on here! (usually red)"
UI.important "Make sure to use Windows (usually yellow)"
UI.header "Inputs" # a big box
name = UI.input("What's your name? ")
if UI.confirm("Are you '#{name}'?")
UI.success "Oh yeah"
else
UI.error "Wups, invalid"
end
UI.password("Your password please: ") # password inputs are hidden
###### A "Dropdown" for the user
project = UI.select("Select your project: ", ["Test Project", "Test Workspace"])
UI.success("Okay #{name}, you selected '#{project}'")
###### To run a command use
FastlaneCore::CommandExecutor.execute(command: "ls",
print_all: true,
error: proc do |error_output|
# handle error here
end)
###### or if you just want to receive a simple value use this only if the command doesn't take long
diff = Helper.backticks("git diff")
###### fastlane "crash" because of a user error everything that is caused by the user and is not unexpected
UI.user_error!("You don't have a project in the current directory")
###### an actual crash when something unexpected happened
UI.crash!("Network timeout")
###### a deprecation message
UI.deprecated("The '--key' parameter is deprecated")
The output will look like this
In the directory of one project, run the tests using
rake test
This will do a few things:
- Runs the tests (you can run them via
rspec
too) - Makes sure no debug code (like
pry
) is still there - The
--help
command works as expected
The tests are executed using fastlane
🚀
To run only a subset of the tests, you can add the now: true
keyword to the test
it "raises an exception if it rains", now: true do
...
end
and then run these tests only using
rspec -t now
The fastlane
repos use rubocop to validate the code style.
The style validation is automatically done when running rake test
.
To automatically fix common code style issues (e.g. wrong spacing), run rubocop -a
Please submit an issue on GitHub and provide information about your setup
Help us keep fastlane
open and inclusive. Please read and follow our Code of Conduct.
Thank you for reading to the end, and for taking the time to contribute to the project! If you include the 🔑 emoji at the top of the body of your issue or pull request, we'll know that you've given this your full attention and are doing your best to help!
This project is licensed under the terms of the MIT license. See the LICENSE file.
This project and all fastlane tools are in no way affiliated with Apple Inc. This project is open source under the MIT license, which means you have full access to the source code and can modify it to fit your own needs. All fastlane tools run on your own computer or server, so your credentials or other sensitive information will never leave your own computer. You are responsible for how you use fastlane tools.