templates/ci-template
Template
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
No description
3 commits 2 branches 1 tag 268 KiB
Find a file Use this template
Exact
Jan Klattenhoff f83c1c5837
feat: setup readme (#2) 
Reviewed-on: #2
Co-authored-by: Jan Klattenhoff <jan@kjan.email>
Co-committed-by: Jan Klattenhoff <jan@kjan.email>
2025-04-09 21:17:18 +00:00
.gitea/workflows feat: setup (#1) 2025-04-09 20:44:06 +00:00
images feat: setup readme (#2) 2025-04-09 21:17:18 +00:00
LICENSE Initial commit 2025-04-09 20:34:37 +00:00
README.md feat: setup readme (#2) 2025-04-09 21:17:18 +00:00
release.config.cjs feat: setup (#1) 2025-04-09 20:44:06 +00:00

README.md

CI Template

A template repository for setting up continuous integration and automatic semantic versioning with Gitea.

Features

  • Automated semantic versioning with semantic-release
  • Integration with Gitea for releases
  • Changelog generation
  • Pull request workflows

Setup Instructions

Follow these steps to set up the CI pipeline and release process:

1. Configure Branch Protection

Add yourself to the whitelist in the release branch protection rule.

Branch protection settings

Don't forget to save your changes.

Save changes

2. Create the Release Branch

Create a new branch named release.

Create release branch

The pipeline for release will start automatically but will fail on the first run. This is expected behavior.

Initial pipeline failure

3. Create the Initial Version Tag

Run the following commands to create and push the first version tag:

git tag v0.1.0
git push origin tag v0.1.0

4. Configure Pull Request Settings

Set up your repository's pull request settings as shown:

Pull request settings

5. Set Up Deploy Keys

  1. Generate an SSH key pair (public and private)
  2. Add the public key to deploy keys named "release" with write access enabled

Deploy key setup

  1. Add the private key to the runner secret as DEPLOY_KEY

Runner secret

Release Process

This template uses semantic versioning through conventional commits. When changes are merged to the release branch, a new version is automatically:

  1. Determined based on commit messages
  2. Tagged in Git
  3. Published as a release
  4. Added to the changelog

Commit Message Format

Follow the Conventional Commits specification:

  • feat: add new feature (triggers MINOR version bump)
  • fix: resolve bug (triggers PATCH version bump)
  • BREAKING CHANGE: redesign API (triggers MAJOR version bump)

Getting Started

After completing the setup:

  1. Remove the images directory and this README
  2. Create feature branches from main for your work
  3. Make changes and commit using conventional commit format
  4. Create pull requests to main (changes should be squashed when merged, although this is not required)
  5. When ready for a release, create a PR from main to release
  6. The PR to release will automatically:
    • Create a new version based on your commits
    • Generate a changelog
    • Merge changes back into main

License

See the LICENSE file for details.