Split antsibull-build's single subcommand into prepare and rebuild-single; deprecate multiple

[felixfontein]

One thing to determine is whether prepare should download the collections already and build changelog and porting guide, as well as updating the changelog.yaml.

I would definitely keep updating the changelog.yaml, but the other things are debatable. @dmsimard what do you think?

[dmsimard]

Need more time to parse the PR, let me get back to you on that

[felixfontein]

I decided to change the prepare command so it really only determines the versions, and doesn't build the changelog and porting guide RSTs.

[dmsimard]

I like this and it helps move in the direction I'd eventually picture things to be like 👍

At a high level: I believe the contents of ansible-build-data should not exclusively be artifacts of a build only pushed after the fact.

We should be able to prepare an upcoming release by drafting a new deps file which would allow the testing coverage to occur before a build and release, not only during. In other words: even though 5.1.0 has not yet been released, I should be able to create a deps file for it and start testing it.

It's OK if the collection versions drift a little until the day of the release -- I figure we can automate collection version updates by re-running prepare and propose a change if there are new versions available.

This would allow us to see problems ahead of time rather than on the day of release.

I will test the PR and report back.

[dmsimard]

I've tested it against a hypothetical 5.1.0 build and the good news is that it works: https://demo.recordsansible.org/playbooks/3221.html
I've pushed the resulting changes to ansible-build-data in a test branch: dmsimard/ansible-build-data@b9da0e5

The prepare command is only poking at the versions: https://demo.recordsansible.org/results/690056.html
And the rebuild-single builds with the deps file that the prepare command generated: https://demo.recordsansible.org/results/690058.html

In the prepare command there's a message that I don't remember seeing before:

Found no release_summary section in the changelog for this release. While this is not required, we suggest to add one with basic information on the release.

The code LGTM at first glance but I am also not intimately familiar with the antsibull internals. There may be an opportunity to simplify further in the future -- for example, while out of scope, I'm not sure if we need build-multiple and build-collection.

[felixfontein]

In the prepare command there's a message that I don't remember seeing before:

That message was probably already there before, but now it's removed. For that I needed to bump the antsibull-changelog requirement a bit (from 0.7 to 0.10; current release is 0.12 so that should be ok).

The code LGTM at first glance but I am also not intimately familiar with the antsibull internals. There may be an opportunity to simplify further in the future -- for example, while out of scope, I'm not sure if we need build-multiple and build-collection.

I think we should remove build-multiple; the code probably isn't tested at all. I will create another PR to deprecate it.

[felixfontein]

When creating that PR I noticed that I would have to re-create parts of this PR (splitting up some function), so I decided to simply integrate the deprecation here :)

[dmsimard]

Works for me, tested locally. Code looks fine too. Thanks @felixfontein !

[felixfontein]

@dmsimard thanks a lot for testing and reviewing!