1
1
ServerPackCreator/CONTRIBUTING.md

5.6 KiB

Contributing

Building ServerPackCreator locally

Clone the webservice branch of the repository:

git clone -b $BRANCH https://git.griefed.de/Griefed/ServerPackCreator.git

Where $BRANCH represents the branch you want to clone.

If you are on linux, run chmod +x gradlew first.

Build with:

build --info --full-stacktrace

The build task is configured to do everything automatically, from installing frontend dependencies, assembling the web-frontend, copying some files around, build and testing.

If you wish to test the installer for your system, run serverpackcreator-app:jpackage --info --full-stacktrace. This will generate the installer in the serverpackcreator-app/build/dist-directory. Depending on your operating system, this may be either of:

  • Windows: ServerPackCreator-VERSION.exe
  • Ubuntu: serverpackcreator_VERSION_ARCH.deb
  • MacOS: ServerPackCreator-VERSION.dmg or other files. It depends on your operating system, really.

Important info regarding pull requests, my GitLab instance, and GitHub!

If you want to contribute to ServerPackCreator, then the following procedure must be adhered to:

  1. Fork ServerPackCreator
  2. Create a new branch in your fork matching your username on GitHub
  3. Make your changes to your new branch:
    1. Try to keep the changes atomic, so they best fit the name of the branch.
    2. Follow conventional commit messages. See Commits-section for more details. See .releaserc.yml for details. Example:
      • feat: Allow upload of modpack-export zip-archive to web-frontend
      • refactor: Use apache commons-io for copying, instead of Files
  4. Open an issue on the main repository, using the Pull Request template:
    1. Issue title: Your Username - Branch type (e.g. feat) - Short description of your changes. Example:
      • Griefed - feat - Allow upload of modpack-export zip-archive to web-frontend
    2. Issue description: Fill in the sections the template provide.
    3. Submit the new issue
  5. I will then create a new branch in the main repository, with the same name as your branch, to which you will then create a pull request to.
  6. I can then merge your fork-branch, push these changes to my GitLab instance, which will in turn push these changes to GitHub.
  7. Done!

This is the only way to ensure that any changes made to ServerPackCreator always arrive on my GitLab instance first, then on GitHub. Since I want to stay independent of GitHub and their architecture, I have to make use of my own GitLab installation. Hence this procedure. So, if one day, GitHub vanishes, we still can provide people with ServerPackCreator from my GitLab instance.

Code

  • Config file: If you want to contribute to SPC, please make sure you do not change the serverpackcreator.conf-file. Ideally, any version of SPC will work with any config file, as they all have the same content. Changing what's inside the serverpackcreator.conf-file may make versions incompatible to each other, but I want users to be able to simply download the newest version without having to migrate their config file or even worrying about such a thing. Therefore, I ask that you do not touch the serverpackcreator.conf-file.

  • Variable names: Please keep variable names verbose i.e. thisStoresSomething or checkForStuff or some such. Variables like a and tmpA make code harder to read. We're not aiming for best performance or whatever, so we can have longer variable names if we want to.

  • Access modifiers: Because the files generated by this program are supposed to be distributed to multiple people, I try to keep methods and classes as closed-off as possible. It's not much, but it's something. Therefore, unless your method or class absolutely must be public, keep it package private or make it private completely. I reserve the right to refactor any such classes or methods.

  • Translating: If you wish to contribute to translating ServerPackCreator, have a look at the resource bundles. Should you want to add a language to ServerPackCreator, add your locale in LocalizationManager, copy the lang_en_us.properties to lang_your_locale.properties and start translating!

Commits

If you want to contribute to SPC, please make sure your commits follow the conventional commit layout and use the types/categories/flags described here: actions/auto-changelog

For completeness' sake:

  • milestone # A milestone release marking a huge step forward in development
  • breaking # Changes that break something makes something incompatible to earlier version
  • build # Changes that affect the build system or external dependencies
  • chore # Other changes that don't modify src or test files
  • ci # Changes to our CI configuration files and scripts
  • docs # Documentation only changes
  • feat # A new feature
  • fix # A bug fix
  • perf # A code change that improves performance
  • refactor # A code change that neither fixes a bug nor adds a feature
  • revert # Reverts a previous commit
  • style # Changes that do not affect the meaning of the code
  • test # Adding missing tests or correcting existing tests
  • improv # A change which improves an already existing feature or aspect
  • deps # Dependency changes/updates/downgrades