chore: check CURRENT_SYSTEM_VERSION matches package.json

[jstarpl]

About the Contributor

This pull request is posted on behalf of the NRK.

Type of Contribution

This is a:

Code improvement

Current Behavior

CURRENT_SYSTEM_VERSION can be mismatched with package.json, potentially leading to weird issues.

New Behavior

There is a test checking if the two values match for a real release (not a pre-release version string). This should ensure that we don't publish versions with a mismatch.

Testing

No testing necessary.

• [ ] I have added one or more unit tests for this PR
• [x] I have updated the relevant unit tests
• [ ] No unit test changes are needed for this PR

Affected areas

Time Frame

Other Information

Status

• [ ] PR is ready to be reviewed.
• [ ] The functionality has been tested by the author.
• [ ] Relevant unit tests has been added / updated.
• [ ] Relevant documentation (code comments, system documentation) has been added / updated.

[codecov[bot]]

Codecov Report

All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 81.49%. Comparing base (2fe0059) to head (3102cdb).

Additional details and impacted files

```diff @@ Coverage Diff @@ ## feat/R51-live-status-gateway-on-R50 #1215 +/- ## ======================================================================== + Coverage 57.95% 81.49% +23.53% ======================================================================== Files 485 145 -340 Lines 79845 27790 -52055 Branches 4160 2252 -1908 ======================================================================== - Hits 46277 22648 -23629 + Misses 33562 5120 -28442 - Partials 6 22 +16 ```

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

[Julusian]

I'm not immediately sold on this test currently. I suspect it will only fail once a tag has been pushed, meaning either replacing the tag, or re-running the portion of the release workflow to bump the version again in order to generate a new tag.

[jstarpl]

I'm not immediately sold on this test currently. I suspect it will only fail once a tag has been pushed, meaning either replacing the tag, or re-running the portion of the release workflow to bump the version again in order to generate a new tag.

Well, since the release procedure for creating the tag in the first place for Core includes running these tests, I was hoping that that would prevent a tag being created in the first place. My first attempt was with a standalone script, but a test case seemed more elegant.

[Julusian]

Well, since the release procedure for creating the tag in the first place for Core includes running these tests

As far as I'm aware, those tests will be run before the version number is changed, meaning it will always contain the prerelease suffix and will skip the check. At the point where the version number is updated (using meteor npm run release), the tag is also created (locally), and the current instructions don't include running tests after that point, other than 'make sure that the new tag builds correctly in jenkins' at which point the tag has been pushed