On 12/06/14 18:08, Dale Hamel wrote:
Workflow would go like this:
0.) Move site to static github.io (possibly using something like jekyll
to make changes easier)
1.) Someone generates a PR, which is reviewed and deemed good
2.) The branch is merged locally, and you run whatever code you had to
do the error number generation as a static page (jekyll could probably
help with this)
3.) You update the master branch and close the PR.
The error pages are not static; they get generated on demand. The list
of possible errors is generated via
make bin/errors bin-x86_64-linux/errors bin-i386-efi/errors ....etc
and then processed into an SQLite database using contrib/errdb/errdb.pl.
When a page within the error namespace is requested, a custom dokuwiki
plugin then uses the database to generate the header information
(including the hyperlinks to the lines of code whence the error might
originate).
It's a very slick process involving absolutely no manual intervention on
my part. Any error added to the codebase will show up in an error page
within a very short time of being pushed to the master branch, and the
pertinent details for the error page (including the full error text) are
pulled directly from the source code.
Or, just pull merge normal PRs like normal, then do add the updated
error code stuff after merging master.
Otherwise, keep the old servers around just for error code /linenumber
lookup. Either way, hosting off of github.io should reduce your hosting
costs and improve reliability.
Hosting costs are zero since I already own a physical server in
Telehouse North, and it all just runs from there. I would be concerned
about the loss of control over hosting on any free external service
(particularly the risk that the service might in future decide to insert
advertisements).
I can help you with the migration (or even just a mockup) if you like -
love the iPXE project and would be happy to contribute in any way that I
can.
Thank you for the offer; I do appreciate it. I have to say that I'm
very happy with the current hosting arrangement and don't really want to
change unless there is a demonstrable benefit which won't increase my
workload.
Michael
_______________________________________________
ipxe-devel mailing list
[email protected]
https://lists.ipxe.org/mailman/listinfo.cgi/ipxe-devel
