kaniko/CONTRIBUTING.md
Guillaume B.B. Van Hemmen ddad91c367 - Add custom Kaniko builder and CI workflows ()
Introduce a custom Kaniko-based image for OCI container builds, including a wrapper script (`build.sh`) for flexible execution. Added Forgejo CI workflows for PR, branch, and tag builds, along with detailed documentation in the updated README. Licensed under Apache 2.0.

Reviewed-on: 
Co-authored-by: Guillaume B.B. Van Hemmen <GuillaumeHemmen@noreply.git.van-hemmen.com>
Co-committed-by: Guillaume B.B. Van Hemmen <GuillaumeHemmen@noreply.git.van-hemmen.com>
2025-05-19 09:48:07 +00:00

3.6 KiB

Contributing Guide

Thank you for your interest in contributing! We appreciate all pull requests (PRs), code reviews, bug reports, and feature ideas. To keep things smooth for everyone, please follow these guidelines.


Table of Contents

  1. Getting Started
  2. Code of Conduct
  3. How to Contribute
  4. Commit Message Guidelines
  5. Pull Request Process
  6. Maintainer Responsibilities
  7. License

Getting Started

  1. Fork the repository and create your own branch.
  2. Clone your fork to your local machine.
  3. Create a new branch for each piece of work:
    git checkout -b feature/brief-description
    

Code of Conduct

All contributors are expected to follow our CODE_OF_CONDUCT.md. Be respectful, inclusive, and open-minded.

How to Contribute

Reporting Issues

  • Search the issue tracker to see if your issue has already been reported.
  • If not, open a new issue and provide:
    • Title: Clear, concise.
    • Description: Steps to reproduce, expected vs. actual behavior.
    • Environment: OS, Java version, etc.
    • Screenshots/Logs: When applicable.

Proposing Enhancements

  • Check existing enhancement requests.
  • Clearly outline:
    • Motivation and use case.
    • Proposed solution or approach.
    • Potential alternatives.

Pull Requests (PRs)

Important:

  • An issue must exist before any PR is submitted.
  • Every PR must link to its corresponding issue in the description (e.g., “Closes #123”).
  • All PRs must be merged using a squash commit.

Steps:

  1. Ensure your branch is up to date with main:
    git fetch origin
    git rebase origin/main
    
  2. Commit your changes (see “Commit Message Guidelines” below).
  3. Push your branch to your fork:
    git push -u origin feature/brief-description
    
  4. Open a PR against main.
  5. Fill out the PR template completely.

Commit Message Guidelines

format: "<type>: <message>"

Allowed <type> values: feat, fix, docs, test, refactor, perf, ci, chore.

Example:

fix: prevent NPE in OrderService when cart is null docs: add README section for Docker usage


Pull Request Process

  1. Ensure the PR description links to its issue
    Use “Closes #” (or “Fixes”, “Resolves”).
  2. Keep the PR focused—one logical change per PR.
  3. Rebase onto the latest main before opening or updating the PR:
    git fetch origin
    git rebase origin/main
    
  4. Push to your fork:
    git push -u origin feature/brief-description
    
  5. Fill out every section of the PR template (tests, screenshots, etc.).
  6. Address all review comments; push additional commits as needed.
  7. Merging strategy
    All PRs are merged using “Squash and merge.”
    This keeps the main branch history linear and clean.
  8. Once approved and all checks pass, a maintainer will squash-merge the PR.

Maintainer Responsibilities

  • Triage new issues and confirm validity.
  • Review PRs in a timely manner.
  • Ensure all CI checks pass before merging.
  • Enforce the squash-merge rule.
  • Keep the documentation and release notes up to date.

License

By contributing, you agree that your work will be licensed under the same license as the project. See LICENSE.


Thank you again for helping make this project better!