-
Notifications
You must be signed in to change notification settings - Fork 8
Contributing to TAP
Developers using TAP can easily contribute to any of the repositories if they would like to fix bugs, improve existing features, or create new ones. Moreover, there is an option to make any of those changes only in private TAP environments, if you consider them specific to your deployment of TAP. This article describes how the contribution workflow works.
Whether you would like to implement a feature or a bug fix, there are some similarities in the contribution workflow that you should be aware of. In both cases, you should first check that the given feature or a fix is not being actively developed by the TAP engineering team or scheduled for future Sprints. To do so, please visit TAP JIRA and go through a pull request, to see if someone is already working on similar solution.
After confirming that no preexisting work exists, you should decide whether your idea should be implemented by the TAP team or if you would like to help and contribute to TAP yourself. In the first case, feel free to create an issue or story on our JIRA instance. In the latter case, please familiarize yourself with the differences between the fix and the feature contribution flows, and how to build, test, and deploy a component with your changes.
Start with verifying that the latest version of a given component does not contain the fix. Also take time to see if there is already a similar pull request on GitHub or issue in JIRA. If you believe that there is no preexisting fix or issue in progress, then consider creating a new JIRA issue for the TAP team or start working on the problem yourself.
Note: Including your proposed fix might introduce incompatible changes, so you should also consider whether or not it is safe for you to do the update. To make that assessment, take a look at the release notes, history of changes, and component version. If a major or a minor version were changed, it’s likely that a single component upgrade is not an option.
If you have chosen to fix the issue yourself, decide whether this is a general fix you would like to share with TAP (which we recommend), or is a specific fix that you want to apply only to your instance of the environment.
If you choose to contribute to the TAP project, your fix should be implemented in the latest version of a given component. Go and fetch the latest version of the component source code from github and start working on it.
If you need a specific fix in the older version of the component, you should apply the necessary changes on top of the commit used to build that artifact. To find out which commit you should use, run following commands:
cf env <APP_NAME>
VERSION: <APP_VERSION>
Once you know the version of your application, you can download the matching artifact (zip archive) that contains the build manifest file with the information regarding commit hash. Now you can start working on your fix.
To introduce a new feature or to modify an existing one, you should follow a similar path as for fixing components.
First, make sure that this feature is not already planned to be implemented by the TAP engineering team or is not already proposed by someone else. You can do that by browsing through TAP JIRA issues.
Once you verified that no one else is working on a similar story, feel free to create a JIRA issue with a proposal for the new feature for the platform.
In case you would like to add or modify a feature yourself, you should fork the required repository and clone it locally. The main difference between adding a feature and fixing a bug is that the source for a new feature should always be fetched from the latest version of the code.
First, fork the repository you would like to contribute to. To get more information about forking a repo and keeping your version of code in sync with the upstream code, follow the standard github procedure: https://help.github.com/articles/fork-a-repo.
Once you forked the repository, create a branch with a meaningful name (name of the feature, keywords for bug, etc.). With a branch, it is easier to add additional commits and push them to update the pull request. To learn more about that, read https://help.github.com/articles/using-pull-requests/. Now you are ready to implement your changes.
Important notes
- Pull in often from the original repository to keep your version up to date.
- Try to keep your code in the style required by the TAP project guidelines.
- Verify that all of the existing tests pass successfully. If needed, implement your own tests.
- Explain in details the motivation for that feature/fix, and the problem you are trying to solve or why you think the feature/fix is needed on the platform. Describe thoroughly what your solution is about.
- When your feature/fix is ready, before creating a pull request and collapse/squash all of your commits into one. Now you are ready to submit your pull request.
- If your code is behind the latest version of the master branch, the repository owner may ask you to rebase and merge the code again, and push it to the existing pull request.
We are looking forward to your contributions!