Store current Skosmos version in composer.json

[osma]

Reasons for creating this PR

Skosmos has been using git tags to infer the current version, which is shown on the About page and in the Generator field in the embedded HTML metadata. This has never worked on Docker containers (which don't have access to the full git repository) and recently it has been broken also in some regular installs.

This PR implements another mechanism, suggested by @kinow in #1202, where the version number is kept in composer.json and read via the Composer runtime API. This ensures that the version information is always available. On the downside, it requires some manual housekeeping to make sure that the version in composer.json is up to date. For now, I think we will do this manually. There are tools that can automate this (see #1202 (comment)) but they didn't look very promising. I will add the necessary steps to the Release Process documentation. I also added a unit test that verifies that the version from composer.json matches the version determined from git tags.

Link to relevant issue(s), if any

• Closes Skosmos version not showing in Docker install #1202

Description of the changes in this PR

• add version number (here, 2.15-dev - I don't think the v prefix is necessary) to composer.json
• use Composer runtime API to access the version number, instead of git operations
• add a unit test that verifies that the version from composer.json matches version determined using git tags
• adjust GitHub Actions configuration so that git version history (including tags) is checked out from the repo, so that the above test has a chance to succeed

Known problems or uncertainties in this PR

I hope the new processes around release will work out well, but we'll find out soon.

Checklist

• phpUnit tests pass locally with my changes
• I have added tests that prove my fix is effective or that my feature works (if not, explain why below)
• The PR doesn't introduce unintended code changes (e.g. empty lines or useless reindentation)

[sonarcloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
0.0% Duplication

[codecov]

Codecov Report

Merging #1308 (c783e96) into master (e6ec026) will decrease coverage by 0.01%.
The diff coverage is 100.00%.

@@             Coverage Diff              @@
##             master    #1308      +/-   ##
============================================
- Coverage     69.45%   69.44%   -0.02%     
+ Complexity     1657     1656       -1     
============================================
  Files            32       32              
  Lines          4070     4068       -2     
============================================
- Hits           2827     2825       -2     
  Misses         1243     1243              

Impacted Files	Coverage Δ
model/Model.php	80.81% <100.00%> (-0.16%)	⬇️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update e6ec026...c783e96. Read the comment docs.

[osma]

I updated the Release Process documentation, see diff

[kinow]

Updated release docs look good, change looks good, tested with Docker Compose locally, all good! 🎉

I think great part of the release process can be automated in GH Actions, another dev did an amazing work at Cylc (previous $work) using plain GH Actions ¹ and some custom actions (Node.js) ². It can even generate PR's to be reviewed and include things like a Release Message ³. For some day.

Footnotes

1. https://github.com/cylc/cylc-flow/blob/master/.github/workflows/1_create_release_pr.yml & https://github.com/cylc/cylc-flow/blob/master/.github/workflows/2_auto_publish_release.yml ↩

2. https://github.com/cylc/release-actions ↩

3. https://github.com/cylc/cylc-flow/pull/4753 ↩

[osma]

Thanks for the review @kinow ! I will merge this.

Thanks also for the tips on release automation, this is very helpful and interesting. I'll open another issue to track those ideas. We've had similar discussions about automating parts of the release process, but for now I think it's best to do that manually.