apps/bunker
2
0
Fork 0
Code Issues 40 Pull Requests 2 Actions Packages Projects Releases Activity
bunker/CONTRIBUTING.md

5.8 KiB
Raw Blame History

Contributing to Bunker

Hey, developer/user! Please, read this file carefully before doing any contributions on Bunker.

Hello from Russia

First of all, hello from Russia and thanks for stopping by.

Lead developer of this project living in Yekaterinburg, Russia. If you're uncomfortable with it - please do not use Bunker and/or do not try to contribute to it.

Issues

Submitting issues

Before submitting issues please make sure you:

  1. Searched for similar issues in tracker.
  2. Asked Telegram chat for help and/or discussion of your issue. It is possible that your problem is a feature or need to be transformed in something else before filing issue in tracker.

Working on issues

See The Flow below.

Developing Bunker

Copyright, licenses, DCOs

Code is licensed under terms and conditions of GNU General Public License version 3. By submitting any portion of code via pull requests you accept that your code will be licensed under this license.

By submitting code via Pull Request you should signoff it (via --signoff command line parameter to git). This will mean:

  1. You signing DCO, meaning that code you submitted was really written by you and not copied from other software (especially with incompatible licensing).
  2. You agree to transfer all rights on submitted code to @pztrn.

Non-signed-off pull requests won't be accepted.

Preparing your development environment

First of all you should properly configure your development environment.

Bunker is developed using VSCode with Go plugin, which utilises gopls and golangci-lint. Ensure linter is running before you commit anything to repositoryto save your time:

  • If you're using IDEA or IDEA-based products (like OpenIDE): use pre-commit to run linter on git commit. It's configuration already added to repository.
  • If you're on VSCode: configure linter to be run on whole workspace to see problems in near-realtime. Fix them before committing code.
  • If you're on any other editor: you're on your own. As example you can take a look on Sublime Text 4 as Golang IDE (russian) or use pre-commit hooks.

The always stable main nonsense

We (and you) should try hard to keep code in main correct, so anyone should be able to checkout code from main branch, build it and deploy anywhere.

Selecting task to work on

First of all, use Gitea's milestones to get epics list. For that filter for next version and use "task type/epic" label filter. Inside these epics you'll find tasks to work on.

After selecting desired task head to Telegram chat and discuss it. There will be always some cases that you'll miss but other developers (or even users) might put your attention on.

Same procedure should be applied to bugs you want to fix. Even if you found it.

Git branches types

There are 3 branch types:

  1. main branch. Trying to keep always buildable and deployable. Only @pztrn is able to merge or commit here.
  2. Feature branches. Named in form of feature/TASKID_feature_name, e.g. feature/2_cicd or feature/123_tasks. These branches created for working on couple of tasks and you should create personal branches from it. Only @pztrn is able to merge or commit here.
  3. Personal branch. These branches located in your personal fork, from these branches you're making merge requests.

The Flow

Bunker uses own flow that can be described like that:

  • Before starting developing something go to Telegram chat and discuss your ideas with others.
  • After discussion an issue must be created in issue tracker. All merge requests should be sticked to one or more tasks in it.
  • Create merge requests early, so other developers and involved users can review you code at any point of time. Follow merge requests template as much as possible and describe your work with as much words as possible.
  • Give commits meaningful descriptions. It can be short, like implement feature X for Y, or linting (if this commit is only about linting), and can be repeated (if you're kind-of ADHD and forgot to fix linting issues on some files while fixing linting issues in others), but it still should be meaningful.
  • Rebase on main or merge it in your branch before calling people to review your code.
  • Your branch should not contain any code that isn't belonging to feature you implement or bug you fix.
  • CI pipeline for linting and tests should pass. Do not call for review if your pipeline failed.
    • Of course, there might be exceptions, e.g. you can't understand why it failing. Head to chat to discuss this situation and request for help.
  • Everything should be covered with documentational changes in docs directory, if needed.
  • @pztrn approve is required to merge. Deal with it for now. This can be changed in future.
  • Merge requests will be automatically squashed in one commit on merging, giving full information about merge request in this commit.

Git flow can be described like that:

  1. Clone Bunker to your account.
  2. Checkout your branch from main branch (or feature branch if specified in task).
  3. Write some code and push it to your copy. Don't forgen about documentational changes if needed.
  4. Create merge request into main repository. Follow merge request template as close as possible. Select proper branch (main or feature branch).
  5. Reiterate 3 and 4 as long as needed.
  6. Ensure your branch gen be merged in destination. Rebase/merge target in your branch if needed.
  7. Call developers to review your code.
  8. If needed, reiterate 3-7 until code is feature complete, CI is green, no objections left in merge request discussions and @pztrn approve is gathered.
  9. Ping @pztrn every day until he merges.

These rules can be changed in any time without further notice.