Runtime testing, What's the CI environment like?

Hal Murray hmurray at megapathdsl.net
Sun Sep 6 22:43:28 UTC 2020


> Possibly, but to test some of the code paths (NTS) would take about a day.
> Who wants to donate machine time for the runner? 

We can test most of the NTS code paths in a few seconds.

What did you have in mind for "about a day"?  The NTS cookie key gets updated 
every 24 hours.  The last-update-time is stored in the file.  We could test 
the update path without waiting a long time by setting up a file that will 
expire in a few seconds.

> Linux distros work, macOS some versions work, FreeBSD yes, NetBSD sorta, MS
> no, and everyone else can check. 

What's the "sorta" for NetBSD?

What do you mean by "can check"?  The idea of this sort of data base is to 
save time on checking and/or to point out holes in our known coverage in hopes 
that somebody will test and report.

I was thinking of a file or web page with a list of known tested cases.  Maybe 
a line per case with OS/distro, version, CPU type, version/date of ntpsec, and 
date of test.

There is a slight chicken/egg problem.  You can't test a released version 
until it is released.

> All refclocks are beleived to work.

Again, some of the gear is pretty old.  I'm sure Eric would be happy to nuke a 
few more drivers.  I'd like to see somebody raise their hand and say "working 
for me" so we could add a version/date line in a file.

Anybody using the modem driver?

I don't think we need a full OS/version/driver matrix.  There are probably 
enough quirks for some drivers that some notes would be useful.  For example, 
the hpgps works with several GPSDOs.  A list of known-working would be nice.

I'm only interested in the current version of ntpsec.  Maybe latest release 
and git head.  I expect some of the reports in the collection would not get 
updated with every release.


-- 
These are my opinions.  I hate spam.





More information about the devel mailing list