Page History

...

git push -u origin KNOX-nnn

3. Implement the feature and commit and push as desired. Note that commit messages should include the issue identifier and the issue title (e.g., KNOX-{NNNN} - {JIRA TITLE}).

git commit -am "<short message about commit>"
git push

...

4. To update the branch from master at any time

git pull --rebase origin master

...

5. To merge the branch back into master, first switch to the master branch and then merge.

git checkout master
git merge KNOX-nnn
git push

...

6. After all code has been merged and the branch is no longer needed, it can be deleted remotely with:

...

git branch -d KNOX-nnn

...

Github Workflow

Recently the Knox project converted our repository to Gitbox. This allows us to merge pull requests directly using the Github interface. In this chapter you can read about the recommended Github workflow on how to use this approach as a Knox contributor/committer instead of the old style JIRA patches.

...

1. Create a branch named KNOX-#### in your local repository and check it out

   Code Block
   # make sure to track local master branch git checkout master # creating and checking out the new branch locally git checkout -b KNOX-####

   
   

2. Mark the status of the related JIRA as "In Progress" to let others know that you have started working on the JIRA.

3. Make changes to the code and commit them to the newly created branch.
4. Run all the tests that are applicable and make sure that all unit tests pass

5. Make changes to the code and commit them to the newly created branch.

   Code Block
   git add [your-changes] git commit -m "KNOX-#### - Your meaningful commit message"

   
   

6. Push your changes. Provide your Github user id and personal access token when asked for user name and password

   Code Block
   git push origin

   Push your changes. Provide your Github user id and personal access token when asked for user name and password

   Code Block
   git push origin KNOX-####

   
   

3.2. Creating a Pull Request

1. Navigate to your fork in Github and create a pull request. The pull request needs to be opened against the branch you want the patch to land.
2. The pull request title should be of the form KNOX-#### Title, where KNOX-#### is the relevant JIRA number
3.  If the pull request is still a work in progress, and so is not ready to be merged, but needs to be pushed to Github to facilitate review, then add [WIP] before the KNOX-####
4. Consider identifying committers or other contributors who have worked on the code being changed. Find the file(s) in Github and click “Blame” to see a line-by-line annotation of who changed the code last. You can add @username in the PR description or as a comment to request review from a developer.
   Note: Contributors do not have access to edit or add reviewers in the "Reviewers" widget. Contributors can only @mention to get the attention of committers.
5. The related JIRA will automatically have a link to the PR as shown below. Mark the status of JIRA as "Patch Available" manually.

3.3. Travis CI

A Travis CI job is configured to be triggered every time

...

• Validate the merge
• Build Knox (using JDK-8 and JDK-11) on AMD64 and ARM64 CPU architectures
• Run unit/integration tests

It is the responsibility of the contributor of the pull request to make sure that the build passes. Pull requests should not be merged if the Jenkins job fails to validate the merge.merged if the TravisCI job fails to validate the merge.

3.4. GitHub Actions

GitHub Actions is also enabled for the project. It is used as an alternative to Travis CI and might become the main CI in the future.

Pros: It is a bit faster than Travis CI

Cons: it doesn't have non-x86_64 nodes for testing on alternative CPU architectures

4. Review Process

All committers who are invited for review are required to follow the instructions in this page and link their Github accounts with Gitbox to gain Merge access to apache/knox in Github.

...

svn ci <modified_files> -m "Change comment"

...