Store current Skosmos version in composer.json#1308
Conversation
|
Kudos, SonarCloud Quality Gate passed!
|
Codecov Report
@@ 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
Continue to review full report at Codecov.
|
|
I updated the Release Process documentation, see diff |
kinow
left a comment
There was a problem hiding this comment.
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 1 and some custom actions (Node.js) 2. It can even generate PR's to be reviewed and include things like a Release Message 3. For some day.
Footnotes
|
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. |









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.jsonand 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 incomposer.jsonis 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
Description of the changes in this PR
2.15-dev- I don't think thevprefix is necessary) tocomposer.jsonKnown problems or uncertainties in this PR
I hope the new processes around release will work out well, but we'll find out soon.
Checklist