Changing Codeπ
Make sure to set up the project before doing this step. You should always create a new branch everytime you develop a new feature, fix a bug or make other changes.
Make changesπ
Now go ahead and make your changes. Take a look at the sub-pages of this page for more information about specific topics. Then come back here to verify, commit and finally submit your changes.
Maven verifyπ
After you made changes, you should also run mvn verify
to check our requirements.
If you have problems solving issues with our requirements there is also a page
Checking Requirements, that you will probably read later.
Improve Build Speed
If mvn verify
takes too long, and you just want a jar, you want to build without checking our requirements.
You can execute mvn package
instead of mvn verify
for that.
But don't forget, you need to successfully run mvn verify
, before you make a pull request on GitHub!
Maven profilesπ
There are some Maven profiles that you can use to change which tests are executed upon mvn verify
and mvn package
.
Some profiles can be used to speed up the build time.
However, you should always run mvn verify
with no enabled profiles before making a pull request on GitHub.
You can use the Test-None
profile to speed up the build process by skipping all tests.
This can be useful when rapidly developing and testing changes in game.
Run mvn verify -PTest-None
or mvn package -PTest-None
or activate the profile in your IDE's Maven tab on the right side.
The Test-All
profile will run all tests, even the ones that are normally skipped.
This is not really recommended, but if you did lots of big changes that
may affect the whole project, you can use this profile to make sure that everything is working.
kRun mvn verify -PTest-All
, mvn package -PTest-All
or activate the profile in your IDE's Maven tab on the right side.
There are more profiles, but you don't need to know them in most cases.
The other Profiles
There are other profiles prefixed with Test-
.
You can use them to select a specific scope of tests that you want to run, after changing code in that scope.
There is also a profile Skip-Verification
, that will skip all verifications.
It is only used in the build pipeline to skip verifications that were already done in earlier pipeline steps.
Commitπ
After you made changes, don't forget to run mvn verify
again.
You should also add a changelog entry at this point.
You need to commit your changes once they are done. You can do this with IntelliJ's Git integration.
Here are a few tips how to make good commits:
A commit needs to be atomic which means it only contains changes that belong together. Large changes may also be split into multiple commits. This makes it easier to understand your changes.
Example: Originally you just wanted to fix a bug, but you also cleaned the code of the class while doing so. Now you should separate these two (logically different) changes into two separate commits. With other words, don't mix up different changes.
Another thing to keep in mind is the commit name and description.
If you fixed a bug, don't write fixed deadlock
.
You should give more qualified information like fixed deadlock, when a huge amount of conditons are cheked at the same time
.
Also, you shouldn't write cleaned the code
, instead you should write things like this renamed methods and variables
.
Next Stepsπ
If you also want to adjust the documentation switch to Changing Docs. Once you are done with all changes, continue with Maintaining Changelog In case you already did that: Continue with Submitting Changes.