particle-os/deb-mock
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
deb-mock/docs/Release-Notes-New-Entry.md
robojerk 4c0dcb2522
Some checks failed
Build Deb-Mock Package / build (push) Successful in 54s
Details
Lint Code / Lint All Code (push) Failing after 1s
Details
Test Deb-Mock Build / test (push) Failing after 36s
Details
enhance: Add comprehensive .gitignore for deb-mock project 
- Add mock-specific build artifacts (chroot/, mock-*, mockroot/)
- Include package build files (*.deb, *.changes, *.buildinfo)
- Add development tools (.coverage, .pytest_cache, .tox)
- Include system files (.DS_Store, Thumbs.db, ._*)
- Add temporary and backup files (*.tmp, *.bak, *.backup)
- Include local configuration overrides (config.local.yaml, .env.local)
- Add test artifacts and documentation builds
- Comprehensive coverage for Python build system project

This ensures build artifacts, chroot environments, and development
tools are properly ignored in version control.
2025-08-18 23:37:49 -07:00

2.6 KiB
Raw Blame History

layout title
default Maintaining ChangeLog

TL;DR - quick start

You typically want to create a markdown snippet with:

$ towncrier create failed-selinux-mountpoint.bugfix
Created news fragment at ./releng/release-notes-next/failed-selinux-mountpoint.bugfix
$ vim ./releng/release-notes-next/failed-selinux-mountpoint.bugfix
... document ...
$ git add ./releng/release-notes-next/failed-selinux-mountpoint.bugfix

Please refer to issues, PRs, bugs, commits using the [reference#ID][] or [some text][reference#ID] syntax described below.

Maintaining ChangeLog

Mock uses the towncrier project for maintaining release notes (aka changelog). For adding a new Release Notes entry, provide a markdown file in the releng/release-notes-next drop-in directory.

Each drop-in file is markdown, and the filename must have <some-unique-text>.<change_category> pattern. The "unique filename" is important, but the name is not used anywhere (choose wisely to not collide with other changes in the next release). For example, let's have a file

releng/release-notes-next/ssl-certs-fixed.bugfix

with contents like:

The SSL certificate copying has been fixed [once more][PR#1113] to use our
own `update_tree()` logic because the `distutils.copy_tree()` was removed
from the Python stdlib, and the new stdlib alternative `shutil.copytree()`
is not powerful enough for the Mock use-cases ([issue#1107][]).

Change categories

Documentation for categories configured in towncrier.toml.

  1. breaking: Incompatible change done. This is mentioned at the beginning of the changelog file to get extra attention.

  2. bugfix: Some important bug has been fixed in Mock.

  3. feature: New feature in Mock has been implemented.

  4. config: Change related to the mock-core-configs package.

Referencing issues or pull-requests

The snippets/drop-in files are in markdown format, so you may simply reference issues with [<type>#<id>][] or [custom placeholder][<type>#<id>]. For example [rhbz#123456][] or [dumping packages][PR#1210]. Currently implemented types:

  1. rhbz#ID: generates `https://bugzilla.redhat.com/ID
  2. issue#ID: generates: https://github.com/rpm-software-management/mock/issues/ID
  3. PR#ID: generates: https://github.com/rpm-software-management/mock/pull/ID
  4. commit#HASH: generates: https://github.com/rpm-software-management/mock/commit/HASH