Add changelog generator to obs service

[jgleissner]

When generating an image description in the obs service module, the service should also generate a changelog from the git commit log, so this could be use later to publish image configuration changes.

There is a bit of a complication. Collecting all commit message since the previous description generation would be simple enough, but the resulting log would potentially contain a lot of messages that do not apply to the image at hand. One potential way to keep the log (mostly) relevant to the image would be to make keg compose a list of all files that were used to generate an image, or perhaps better break it down by profile, as multi-build profiles result in separate binary images and we do publish changes for them separately. The resulting lists could be fed into git log to collect only commit messages that apply to the binary image. It still won't be 100%, as many files provide input for multiple images and a commit to them may only affect a subset, but I think it would be way better than including the whole lot.

[rjschwei]

I agree we do not want to take a "dump everything" approach for changelog generation.

I think the looking at things on a per file basis is a good first step. In addition we could potentially comprehend at least some of the diffs since we have flavor specific things listed in flavor prefixed sections. Such comprehension would narrow down the margin of error further.

[jgleissner]

There's another point I'd like to raise for discussion. I've basically have the changelog generator ready. At the moment it produces a simple list of changes which could be handed to osc vc to produce a changelog entry. However, I'm not sure whether the changelog format that packages use is the best way. In the end we probably want to add this information to the set of changes HTML pages. So a more parseable format may be better, e.g. we could produce a json file, something like:

{
  "1.1.0": {
    "date": "2021-12-03"
    "changes": [
      "change1",
      "change2"
    ]
  }
}

This should make processing the data later on a lot easier. Of course, this isn't very nice for humans to read. Not sure whether we care that much about at this point. We could generate a json and a text file, of course.

Opinions?

[jgleissner]

Also, we should agree on some rules for the commit message format to make sure we generate consistent change logs. I suggest we just use the subject line of the commit message for each change log entry to keep it (relatively) compact, which would mean that the subject line should contain a brief summery that makes sense to the user, plus any references (bugzilla, CVE, Jira). So the suggested format would be:

User-friendly summary (bsc# CVE etc)
{empty line}
Message body (description of changes).

The summary line should not start with a dash as it's not part of a list. If we go with my suggestion the format of the body would not be relevant to the change log so I don't think we'd need to mandate a specific format for it.

[rjschwei]

The changelog pages were designed and implemented to be html so we get the best of both worlds, parseable and human readable in a browser. I do agree that the package changelog format is not very conducive to automatic processing as such we can certainly create something that has a different structure. I am not certain that we need to have a json format here only to then transform it to html in a post processing step, why not have this generator produce the final result so we can "just" stick it into the html structure? I do not see the advantage of having an intermediate format. I suggest something simple along the lines of

<ul>
  <li><h4>User-friendly summary (bsc# CVE etc)</h4>
  <ul>
    <li>Message body (description of changes).</li>
  </ul>
  </li>
.......
</ul>

[rjschwei]

I agree with the commit message format, but think the message body should be part of the changelog

[jgleissner]

We would spread the "knowledge" about the change info format over two separate tools, and we'll still have to touch the change log document to amend it with the cloud image name, but I get the point about the intermediate format that doesn't serve a real propose. I'll implement it that way.

[jgleissner]

I was looking into adding HTML output to the change log generator, but there's an issue. The HTML page that is supposed to contain the image configuration changes also contains information about added and removed packages. The latter is already produced by the change info generator. So producing a HTML page with the commit messages isn't actually particularly useful, as the change info page generator would need to process it after all in order to include it in the image configuration page. That means writing the commit message log in a format that is easier to parse than HTML is preferable IMHO.

[jgleissner]

This has been added.