Check the presence of changelog for the latest stable release in History.md

[ia]

• Please check if the PR fulfills these requirements

• The changes have been tested locally
• There are no breaking changes

• What kind of change does this PR introduce?
  Detecting the presence of changelog for the latest stable release in History.md.

• What is the current behavior?
  We should add changelog manually but sometimes we may forget because there is no any test check for this.

• What is the new behavior (if this is a feature change)?
  Extend test step for docs using GitHub Actions with the following algorithm: check History.md for the latest stable release, check git tag for the latest stable release, and if they mismatch then trigger error.

• Other information:

Not sure how it will work at the moment of tagging though. I guess we will see. :)

But basically now the push of the new release tag to dev must be with the same commit of changelog to History.md. Otherwise there will be a reminder in the form of red build, but next commit of changes to History.md probably will fix it. That's the point after all.

Another one important notice for contributors, or what's new today I learned about git/hub: sometimes tags must be synced manually because for some reason just merging with upstream is not enough to sync some metadata such as tags, i.e.:

(in your local directory with the forked repo)
$ git fetch --tags upstream
$ git push --tags

Without this, Actions in forked repos may not be fetching the latest actual git tags from upstream even if anything else is properly merged, synced, and up-to-dated. 🤷‍♂️

[discip]

@ia
Although I understand roughly what this does, I not capable to approve your changes as I am not a programmer and therefore lack the necessary expertise. 😅
So you will have to wait for Ralim to approve it.

[ia]

@ia Although I understand roughly what this does, I not capable to approve your changes as I am not a programmer and therefore lack the necessary expertise. 😅 So you will have to wait for Ralim to approve it.

Oh, sure. The thing is, it seems something slightly changed with PR submission recently: before Ralim and you would be added automatically as reviewers for my PRs (which was convenient) but now it seems GitHub uses some sort of AI "guessing" who is more "relevant" for each PR. 🤷‍♂️

So now I just have to be more careful to make sure that both of you are included just in case.

The bottom line is the point was include both of you as always just in case but I think GitHub included originally only you first or no one at all. So, that's what happened so you know.

[Ralim]

We should add changelog manually but sometimes we may forget because there is no any test check for this.

aka I will always forget as I'm terrible at remembering stuff like this

I absolutely love this

Not sure how it will work at the moment of tagging though. I guess we will see. :)

It will break the CI build when I make the tag. Which isn't the best time to break but its a lot better than not. As that will poke me at the least.

Once this is merged I'll update the expected CI values too (since check_readme wont exist)

Are you feeling happy with this @ia ?

[ia]

I absolutely love this

Thanks. :)

Not sure how it will work at the moment of tagging though. I guess we will see. :)

It will break the CI build when I make the tag. Which isn't the best time to break but its a lot better than not. As that will poke me at the least.

I know, right? Exactly the point. Just right after new release tag History.md should be updated. I cross my fingers there won't be any false positive/negative triggers besides that.

Once this is merged I'll update the expected CI values too (since check_readme wont exist)

A, oh, yeah... at first I didn't get it but now I think I got it: I was thinking to keep check_readme title not to bother you updating build steps manually, since I'm aware that once we change any meta info in push.yml/Actions, you have to make manual updates in GitHub project settings to reflect changes. However, not to confuse anyone in the future (including future me), I just decided to name things properly. At least now we have a separate test step for docs only, so it could be extended in the future without changing meta info about build step itself anymore (just like we have it already for Python scripts and C/C++ code).

Let the machines do the machinery. ;)

Are you feeling happy with this @ia ?

Sure! As always happy to be useful.