ci(): Add a check for changes to changelog

[asturur]

This pr adds an additional check to verify if the user add the correct changes to the changelog.
The reason for this is that we often forget to add it.
Better some extra conflict on PRs rather than an empty changelog, there are automated tools that could pull out a changelog out of commit messages, we have one, but i personally do not use commits in a meaningful way and i use them more as save points rather than concise small changes. And i don't rebase, because i often mess up and i have better things to do.
So i squash and i do write manually a meaningful changelog line

[github-actions]

Coverage after merging changelog-check into master will be

82.44%

Coverage Report

File	Stmts	Branches	Funcs	Lines	Uncovered Lines
HEADER.js	54.90%	48.15%	0%	65.22%	105, 105, 105, 12, 14, 14, 14, 14, 14, 16–17, 21, 21–22, 22, 22, 24, 24, 26, 28, 30–31
src
cache.ts	97.06%	90%	100%	100%	57
canvas.class.ts	93.44%	90.36%	94.23%	95.58%	1077, 1077–1078, 1081, 1101, 1101, 1136, 1169–1170, 1198–1199, 1232, 1240, 1350–1351, 1353–1354, 1374–1375, 1533, 1538, 1548, 1552, 485–486, 491, 500, 649–651, 696–697, 761–762, 765, 767, 814–816, 858, 863–864, 892–893
config.ts	77.27%	66.67%	66.67%	84.62%	130, 138–140, 151–153
constants.ts	100%	100%	100%	100%
intersection.class.ts	100%	100%	100%	100%
pattern.class.ts	92.19%	85.71%	100%	96.30%	110, 116, 127, 136, 88
point.class.ts	100%	100%	100%	100%
shadow.class.ts	95.95%	90%	100%	100%	172, 239, 8
static_canvas.class.ts	90.10%	83.79%	96.70%	92.75%	1152–1153, 1153, 1153–1154, 1288, 1354–1355, 1358, 1407–1408, 1501, 1516, 1520, 1546–1547, 1576–1577, 1610–1611, 1652–1653, 1656, 1658, 1658, 1658, 1658, 1662, 1662, 1662–1664, 1686–1687, 1728–1729, 1732, 1734, 1734, 1734, 1734, 1738, 1738, 1738–1740, 1813, 1813–1814, 1873, 1875, 1875, 1875, 1875, 1875–1876, 1879–1880, 1880, 1880–1881, 1884, 1884, 1884, 1886, 1889, 1895, 1897–1898, 1898, 1898, 1901–1902, 1902, 1902, 1905, 278–279, 281–282, 284–285, 298–299, 301–302, 616, 642, 698–701, 901
src/brushes
base_brush.class.ts	100%	100%	100%	100%
circle_brush.class.ts	2.99%	0%	0%	3.92%	100–101, 103, 105–107, 116, 116, 116, 118, 120, 122–124, 126–129, 137, 144, 146, 26, 31–32, 40–44, 48–52, 59–62, 70–74, 76, 84, 84, 84, 84, 84–85, 87, 87, 87–90, 92
pattern_brush.class.ts	5.26%	0%	0%	8.33%	16, 20–23, 25–26, 26, 26–29, 37–38, 40, 44, 55, 55, 55, 63–65, 65, 65, 72–73, 75–76, 76, 80
pencil_brush.class.ts	91.95%	85.42%	100%	93.69%	125–126, 155, 155–157, 279, 283, 288–289, 71–72, 87–88
spray_brush.class.ts	2.30%	0%	0%	3.08%	102–104, 106–107, 115, 115, 115, 115, 115–116, 118–119, 126–127, 129, 131–135, 144, 148–149, 149, 157, 157, 157–160, 162–165, 169–170, 172, 174–177, 180, 187–188, 190, 192–193, 195, 202–203, 205–206, 209, 209, 216, 216, 220, 25–26, 28–30, 30, 30–32, 36, 45, 52, 59, 66, 73, 80, 92–94
src/color
color.class.ts	91.67%	84.51%	100%	94.44%	325–326, 330–331, 334–335, 41, 45, 72–73, 73, 75, 75, 75–76, 78–79
color_map.ts	100%	100%	100%	100%
constants.ts	100%	100%	100%	100%
index.ts	100%	100%	100%	100%
util.ts	100%	100%	100%	100%
src/controls
control.class.ts	90.24%	81.48%	86.67%	97.50%	210, 304, 304, 348, 372, 6
controls.actions.ts	76.80%	69.20%	93.75%	80.67%	161, 163, 163, 163, 165, 167, 26, 28, 28, 28, 290–293, 321, 323, 330–331, 333, 333–334, 336–337, 341, 373, 375, 382–383, 385, 385–386, 388–389, 393, 421–422, 424, 426, 431, 434, 434, 434–435, 435, 435, 437, 437, 437–438, 438, 438, 441, 441, 441–442, 442, 442, 475–476, 478, 480, 485, 488, 488, 488–489, 489, 489, 491, 491, 491–492, 492, 492, 495, 495, 495–496, 496, 496, 520–522, 528, 528, 528–529, 532–535, 537, 537, 537–539, 539, 539–541, 543, 543, 543–545, 545, 545–546, 551, 551, 551–552, 554, 556–558, 57, 589–590, 592–594, 641–643, 8, 841
controls.render.ts	85.11%	84.78%	100%	84.78%	23, 27, 42–49, 58–59, 82, 86
default_controls.ts	94.29%	50%	100%	100%	115, 83
src/filters
2d_backend.class.ts	96.43%	83.33%	100%	100%	78
WebGLProbe.ts	40%	40%	57.14%	34.78%	38–39, 49–53, 61, 64, 66, 66, 66–67, 67, 67–70, 72, 74, 78
base_filter.class.ts	28.90%	31.82%	36.36%	26.17%	100–102, 102, 102–103, 112–116, 116, 116–117, 124–125, 125, 125–128, 143, 159, 169–174, 178, 181, 181, 181–184, 184, 184–185, 185, 188–189, 195, 204–205, 210–214, 257–260, 273, 273, 273–274, 276, 292–294, 294, 294, 294, 294–295, 297, 299–300, 306–307, 309–311, 315–316, 318, 322–324, 328, 332, 352, 352, 352–356, 393, 78, 78, 78–79, 79, 79–80, 80, 80–81, 86–89, 89, 89–90, 99

[ShaMan123]

I prefer the same and use committing the same
So the changelog becomes purely manual or a dev that uses commit messages can use the automated tool and commit the output?

[ShaMan123]

For future reference could you write how to use the automated tool?

[asturur]

npm run changelog is what we have right now, but is based on master changes, so is not valid for PRs changelog.
Is just a tool to backfill the changelog when we forget to add it

[ShaMan123]

updated contributing 695d2d2

[asturur]

@ShaMan123 is there something you want to think about or can you review this?

[ShaMan123]

see comments

[ShaMan123]

remove this line, copied by mistake

[ShaMan123]

Suggested change

- name: Code Coverage Report Updater

[ShaMan123]

The naming of this option is confusing
From the docs:

The check can be disabled for a PR with a label. This label can be customized with the noChangelogLabel parameter.
https://github.com/Zomzog/changelog-checker/blob/master/action.yml#L12

So no need for it
I agree they should have added an option to customize the title

[asturur]

mmmm but i have seen that going out in the console? let me check again

[asturur]

i definetely got confused with this:

i simply copied their example and smashed in, i didn't even search for a doc page

[asturur]

initially i tought this would be the message that goes on the github check section, when failed. Then i see it wasn't and moved on

[ShaMan123]

typo git hub

[ShaMan123]

I have another thing I want ci to do in this scope.
Once published it should modify the changelog by replacing the next tag with the published tag and add a new next section.
That will safeguard forgetting to do it before releasing, which will happen for sure.

[ShaMan123]

If we are going in that direction why not have an action run on PR merge to master that writes to the changelog the PR commit message which is meaningful always instead of doing it as part of the PR?

[asturur]

If we are going in that direction why not have an action run on PR merge to master that writes to the changelog the PR commit message which is meaningful always instead of doing it as part of the PR?

I don't like automated commits. Is a changelog you have to add in the file, we should just do

I have another thing I want ci to do in this scope. Once published it should modify the changelog by replacing the next tag with the published tag and add a new next section. That will safeguard forgetting to do it before releasing, which will happen for sure.

You can do it, this is more a daily issue.
But even if you forget to update the version in the changelog nothing happens.

[ShaMan123]

came across https://github.com/marketplace/actions/automatic-releases

[ShaMan123]

OK I understand the missing piece.
We should use versioning differently.
A release should end the life of a version and not start it.
It is confusing that there's a release for 5.1.0 and master is still on that tag.
We should increment the version after the release and not before. Thus, starting a new version.
Then the changelog could have the current tag as the header instead of next.
What do you think?
Well I do get that incrementing a major version is done hindsight...
What is the flow of versioning and releasing? Let's plan it and make CI take over.

[ShaMan123]

I see that CodeQL is failing due to syntax
https://docs.github.com/en/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/configuring-code-scanning#using-a-custom-configuration-file

[asturur]

well since i applied all the requested changes i m using the admin power and merging.
You are talking about unrelated ideas to this PR

[asturur]

OK I understand the missing piece. We should use versioning differently. A release should end the life of a version and not start it. It is confusing that there's a release for 5.1.0 and master is still on that tag. We should increment the version after the release and not before. Thus, starting a new version. Then the changelog could have the current tag as the header instead of next. What do you think? Well I do get that incrementing a major version is done hindsight... What is the flow of versioning and releasing? Let's plan it and make CI take over.

The flow till now is that i would increment the version at the moment of tagging, because i didn't want devs to read a new version number that didn't exist yet. Also until is release time you don't know which release number you will get, unless you release every single commit that for me is an overkill unless we talk about bug fixes.

Fabric development has always been a gut feeling thing, today i fix this, today i add that, so one day you could have a patch or a minor, and always tried to keep at minimum the major releases

now changing development flow is entirely possible, i don't like to release each commit and i don't like to have many active branches either.
It is also fine to release with a regular cadence, immediately for bugfixes with no refactors, and on a regular cadence for the other things ( like once a month ).

[asturur]

we can swap the master version to 5.99 now just so that we don't get confused

[ShaMan123]

I found a bot that will comment if the changelog hasn't been updated and is more configurable and verbose but is unrelated to tests so it seems
https://github.com/behaviorbot/update-docs