This repo https://github.com/danack/PHPDocTool will do all the stuff necessary to check out the docs, and PHD then render it locally, and watch for any changes on the file system, at which point it will rebuild just the changes.
The good news is rebuilding just the changes in isolation is really quick (a few seconds) the less good news is that because the build is done in isolation, there is some stuff missing e.g. if you make a change in Imagick::adaptiveBlurImage, that page will be updated.......but it will lose all links to other Imagick methods, because the class index was included in the partial render.
btw, that tool currently uses
git ls-files -m to find the modified files. This apparently makes Docker very angry, and shouldn't be left running indefinitely.
@salathe Do the repos for the doc-base and the PHD renderer have tests setup for them? Obviously using the same code that is actually run to build the manual as for CI and local tools would be good, but I think I'd like to make some changes to configure.php in doc-base, and possibly the PHD renderer to make it possible to i) call them as functions rather than having to invoke them through the command line ii) be able to compile small chunks of the manual, in a way that produces an output that is more like the full manual build rather than the current partial rendering, due to the indexes being lost.
If they have tests, then making changes would be reasonably safe.....if not, then no.
I'm going to play with the github notifications next and look at rendering pull requests.....I'm going to stick with a separate tool rather than just using Travis for now, as I still think having the build results be almost instantaneous and viewable online will be better than Travis which can lag and would need to have the results pushed somewhere else to be viewed.
But ....it is possible that I might change my mind and just shove it in favour of Travis.
I've been played with the misspell-fixers and Travis
And I didn't get round to testing anything sadly as well. 😔
FYI What I was going to say tonight was that:
i) making sure the configure.php in the doc-base repo and the phd render have tests would be a good thing to have done eventually. Currently that code can only be used via the command line, which is slightly annoying, but also the partial render can only render one file at a time, which is quite annoying. Changing that to be better would be not too difficult to do, but obviously would be better once someone has checked that there are enough tests in place to make sure rendering the manual doesn't break.
ii) I'm going to crack on improving https://github.com/danack/PHPDocTool to make it have a front-end that shows what it's doing (and what was recently rendered), to have a place where you can drop in the url of a github fork of the docs and have it render that before a PR is opened, and anything else sensible I can think of.
But looks like I didn't really miss anything :D
Have you seen this? :joy:
Btw, I'm a little bit absence due to some stuff from work, but, next week, I pretend to re-schedule our Hangouts, so we can align in what step we're in this migration.
Ahh, just saw it in the internals@.
I don't think that this will affect us.
@nikic Aren't we using the git.php.net domain for this migration?
Or only in ways that makes things simpler :)
And then it should be possible to run a cront-task that retrieves the new stuff from SVN, replaces the IDs with the hashes and then pushes to the main repo .
It should be sufficient to run that on an hourly schedule....
it will run the filter on the local copy and then push the altered commits to the upstream repo
Or is Thursday better?
Also.....I'm pissed off at docker. I'm pretty sure that we could make a really nice UX for a local editor tool that does things like automatically jumps to the file you've been editing.
Except that the whole filesystem is just too slow in Docker to be able to watch or handle as many files as there are in the manual.
So.....i'm chucking all of those ideas away, and reverting to some bash scripts that will run on the host machine instead.
But I managed to get
git filter-branch going. Running it on the german translation took about 15 hours, but now all the Revision-IDs are replaced with the corresponding hashes!
Now I need to automate that process to only run from the last successfull hash on...