Changelog Meta Processing

Monteur has a special metadata processing function for sourcing and processing changelog entry. The inner mechanics are explained here!

The Problems

It was all started when performing a packaging with Package Meta Processing where each package has its own version and format of changelog output files.

Generally speaking, it was very messy to generate different set of changelog based on the packager type and requirements. Some packages, like .deb type, has platform specific in its changelog and essentially made the generation efforts even more complicated at scale; some like .appimage does not need a changelog at all.

Another issue is that there are various version control system like git, svn, and etc. Hence, this complicates the process of sourcing the latest changelog entry and trying to simplify all of them into a single maintainable yet simple CI Job recipe.

The Solution

To solve the problems above, Monteur uses this Changelog Meta Processing approach to facilitate changelog sourcing and output formatting as a preprocessor. This approach works closely with Package Meta Processing function.

The idea is to:

  1. Provides a 2-stage Commands Execution Unit (CEU) commands execution where:

    1. The 1ST stage source and process the changelog data; AND

    2. The 2ND stage actually runs the recipe's actual CEU commands.

  2. Matchmaking closely with Package Meta Processing function to ensure the changelog data and filepath are always aligned.

By doing so, we kept all kinds of version control system interfaces independent of Monteur while still able to work with any number of changelog generations or updates.

Current Deployment

Currently, this function is deployed in the following CI Jobs:

  1. Prepare since Monteur version v0.0.2.

Available Formats

Montuer facilitates a list of built-in changelog formats for updating the changelog files seamlessly. To select the format, you set it via Metadata.Type field. For example:

1
2
3
[Metadata]
...
Type = 'deb'
Available formats are:

Data Structure

To operate this function, Monteur uses a single unified changelog data structure alongside Package Meta Processing data structure. Hence, there are 2 parts of it so the following sub-sections shall detail them from top to bottom in sequences.

Changelog Data Structure

The first part would be the Changelog Data structure itself. This section, when made available via [[Changelog.CMD]], SHALL BE EXECUTED before anything else. This is to ensure Monteur obtained all necessary input before actually executing the actual recipe's job.

The successful changelog extraction are saved into ChangelogEntries variable made available for recipe's CEU command.

The full data structure is shown below:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
...

[Changelog]
LineBreak = "\n"
Regex = ''

[[Changelog.CMD]]
Name = "Fetch All Local Remote Branches To The Latest"
Type = 'command'
Condition = [ 'all-all' ]
Source = 'git fetch --all'

[[Changelog.CMD]]
Name = "Get Changelog Data from Git Log Between Branches"
Type = 'command'
Condition = [ 'all-all' ]
Source = """git --no-pager log \
"{{- .ChangelogTo -}}..{{- .ChangelogFrom -}}" \
--pretty="format:%h %s"
"""
Save = "ChangelogEntries"
  • Changelog.LineBreak

    1. COMPULSORY - The line break characters for parsing.

    2. By default or when in doubt, it's \n. This field is for some operating system and software that uses other symbols like carrier return (e.g. \r\n).

    3. Available since Monteur version v0.0.2.

  • Changelog.Regex

    1. COMPULSORY - The regular expression field for capturing the changelog.

    2. Can be left empty to indicate the entire output are indeed the exact changelog entry.

    3. Available since Monteur version v0.0.2.

  • Changelog.CMD

    1. OPTIONAL - List of commands complying to Commands Execution Unit specification.

    2. RECOMMENDED NOT TO USE ANY -quiet CEU type to make sure the recipe fails early when something went wrong.

    3. List can be left empty or completely absent to indicate that the recipe is not preparing a changelog update but working something else like project version.

    4. Available since Monteur version v0.0.2.

Package Data Structure

The second part would be the list of packages data structure itself. This sole purpose is to update all packages' changelog data file with the newly obtained changelog entry data.

The data structure is fully compliant to Package Meta Processing Specification. Moreover, when changelog is used, the package list SHALL MATCH AND MAP EXACTLY with the corresponding Package CI Job's Recipes.

An example of the data structure is shown below:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
...

[Packages.linux-amd64]
OS = [ 'linux' ]
Arch = [ 'amd64' ]
Distribution = [
        'stable',
]
Changelog = '{{- .DataDir -}}/debian/changelog-{{- .PkgArch -}}'

[Packages.linux-arm64]
OS = [ 'linux' ]
Arch = [ 'arm64' ]
Distribution = [
        'stable',
]
Changelog = '{{- .DataDir -}}/debian/changelog-{{- .PkgArch -}}'

[Packages.linux-armhf]
OS = [ 'linux' ]
Arch = [ 'armhf' ]
Distribution = [
        'stable',
]
Changelog = '{{- .DataDir -}}/debian/changelog-{{- .PkgArch -}}'

...

Epilogue

That's all for Monteur's Changelog Meta Processing function. If you have any question, please feel free to raise your question at our Issues Section.