Also test against Tahoe-LAFS master on CI #285
Conversation
Codecov Report
@@ Coverage Diff @@
## main #285 +/- ##
==========================================
- Coverage 91.76% 91.72% -0.05%
==========================================
Files 51 51
Lines 4689 4689
Branches 645 645
==========================================
- Hits 4303 4301 -2
- Misses 338 339 +1
- Partials 48 49 +1
Continue to review full report at Codecov.
|
exarkun
changed the title
There was a problem hiding this comment.
I think for this to be useful, we need to either update the pin when running CI, or at least have a periodic job that does that (and possibly pushes the result if CI passes). Otherwise, I'm not sure what having a separate niv entry does, that we couldn't get by updating the current one and pushing to CI.
I think I preference would be the third option (run a job in CI periodically, that update the pin and pushed that change if CI passes).
My plan for now is to manually do the update once a week (similar to how we do the nixpkgs update elsewhere). I'm not sure I want to build GitHub-based automation for this update since ideally we'll move the project to GitLab. |
|
I pushed some doc additions to record the current and future plans. |
CONTRIBUTING.rst
Outdated
| It is also possible to pass ``pull/<pr-number>/head`` to test against a specific PR. | ||
| When feasible we also test against a released version of Tahoe-LAFS. | ||
|
|
||
| The Nix package depends on a version of Tahoe-LAFS determined by the "tahoe-lafs" niv entry. |
There was a problem hiding this comment.
I know that "nix packaging" == "what is deployed on storage nodes", but it might make sense to be explicit about this.
Maybe something like "The package deployed on our storage node depends on the version of tahoe indicated by the tahoe-lafs niv entry..."?
There was a problem hiding this comment.
Maybe it would also make sense to have this section first, given that it is the one that is consumed outside of CI.
| .. note:: | ||
|
|
||
| Since tahoe-lafs doesn't have correct version information when installed from a github archive, | ||
| the packaging in ``default.nix`` includes a fake version number. | ||
| This will need to be update manually at least when the minor version of tahoe-lafs changes. | ||
|
|
||
| If you want to test multiple versions, you can add an additional source, pointing at other version | ||
| If you want to test additional versions, you can add an additional source, pointing at other version. |
There was a problem hiding this comment.
I think I'd be inclined to put the tahoe-lafs-master instructions after this, partly as an example of testing against additional versions.
Fixes #281