Not to speak for Jay, but I think the package server's primary role is
to be a catalog server -- "given a package name, I'd like to cash that
in for some code". For projects hosted at Git{Hub Lab}, that means the
package server needs to know the project URL and the commit digest. It
refreshes the latter automatically (hourly, I think?). But if you're in
a hurry, you can click Refresh Packages.One consumer of the package/catalog server -- but a distinctly separate thing -- is the build server, which runs daily. This does "CI" testing. Since part of building packages with docs is rendering the docs, it saves the results to use for docs.racket-lang.org. I think it's usually a good idea to set up your own CI, using something like Travis CI (or Circle CI, or the CI built into GitLab). That will give you quicker feedback. Also it can run automatically on code you push to topic branches and run on pull-request branches -- before it even gets merged to master. (I like to set GitHub repos to protect the master branch, so that even I the repo owner can't push directly to master, until things pass CI on a topic branch. This saves me from lazy-didn't-run-the-tests-Greg more often than I would like to admit. Also it helps me discover problems on an older version of Racket that I am still trying to support.) So, I think of the daily build server more as a last line of defense, when it comes to CI. Admittedly, when it comes to docs, it can be frustrating to wait up to a day for those to be refreshed on racket-lang.org. However people who install or update the package will get the new docs built locally. -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
