sip-changelog v1.0.2

This tool allows to write SIP Process Conform changelogs.

$ ./bin/sip-changelog \
  --story-match MYX \
  --group-by-tag 'dt-release_2_0-(.*)'

This tool produces a Changelog from the git history. If there are release or deployment tags set within the git a grouping per tag is done. This grouping enables to generate a changelog between the grouped tags. The grouping is generated via a regex which is applied to the tags. An other grouping is generated by the story-match which is also an regex so that the first group of the regex 'MYX-(\d+)' is used for sorting the stories with each group. It story-match is not matching to commits the not matched commits will not be shown.

Je Release ein Changelog bereitstellen, in dem jedes Build mit den Changes zum letzen Build des Releases vorhanden ist (beginnend ab Start-SHA) mithilfe von TAGS (statisch für das Release) und dynamisch (für den Build) - enthalten sein sollen Changes auf der Basis von Jira-Tickets - keine Committs.

Idee ist, das im Git zu Taggen. Ein Tag ist Fix (Releasename) und einer Dynamisch (Lfd. Nummer des Release-Builds). Beide zusammengesetzt sind dann die eindeutige Version eines Release-Builds...

Sample-File WIP-7 fix WIP-7 fix WIP-7 missing alot of features WIP-1 fix WIP-1 missing alot of features WIP-2 chore WIP-2 fix WIP-2 WIP-19 fix WIP-19 dt-lux-4 WIP-3 chore WIP-3 WIP-4 fix WIP-4 dt-lux-3 WIP-1 fix WIP-1 dt-lux-2 WIP-7 fix WIP-7 WIP-11 fix WIP-11 dt-lux-1 WIP-15 fix WIP-15 fix WIP-15 dt-lux-start WIP-4 fix WIP-4

Acceptance-Criteria AC: Every Release-Branch will have a Start-TAG st- (Git-Syntax-konform) AC: Every Release-Branch will be named rb- AC: Every deployment will have a specific TAG “dt---” (Zielumgebung: MSI/INT/QA/LIVE/NONE) (timestamp will be the one of the last SHA in the Release-Branch) AC: The root package.json will contain a key ‘sip.name’, ‘sip.gitname’ that holds the Release-Name (display-Name) AC: JIRA-Releasenames will be normalized to the technical-Releasenames used in Git/Jenkins with a standardized specification. The representation will be injective. (It’s not possible, to rebuild the JIRA-Name from the technical-name). AC: For every Deployment a (dynamic) TAG will be created at the deployed SHA. AC: The Release-Notes will be provided in JSON (Step 1) AC: The Release-Notes will be provided in plain text (Step 2) AC: The Release-Notes will be provided in MarkDown (Step 3) AC: Step 1 JSON Structure: “{Ticket-ID:{Day of Commit:commits,...}}” AC: Step 2 plain text Structure: “Ticket-ID /n /t Day of Commit /n /t/t commit 1...” AC: Step 3 MarkDown Structure: “Ticket-ID { conflucene-url} /n /t /n /t/t commit 1 {git-url} ”

AC: The JSON, plain text and MarkDown will be placed into the directory docs/_docs/05-changelogs/cl---<timestamp.json | txt | md AC: The URL of the Release-SIP-Page will be placed into the root package.json (e.g. confluence-199199941) sip.confluence.url AC: technical integration commits not relevant for testers will be marked separately within a commit message: “fix: Unable to render embedded object: File (MYA-\d+) not found. ”

Thx to sinnerschrader