Currently a senior technical writer for AWS IoT. Previously: professor of Technical Communication, Programmer/Writer, Software Developer, Air Force officer, & Electronics Technician.
Not being able to test intermediate (or local) builds was a problem I had earlier and I also thought that auto building would be the only way.
But, then I had a simpler idea: fork my own repo.
Now, the "published" documentation (what I want the world to see) is in my main account in the github pages doc folder of the project repo. I then created a separate, development account into which I forked the published repo. From the forked repo, I can test and publish (to another URL that I don't tell people about) as github pages automatically builds the work-in-progress docs under the development repo. When I like my changes, I send a pull request to the published repo to update it.
With that scheme, no hosting is required, no building is required, and you get instant (and manageable) documentation with no need to spin up (and manage) a server.
Yes it has some Jekyll limitations, but for the minimalist case where you don't want to manage any build or hosting servers, the tradeoffs might be worth it.
That's a good workflow you have there. You should consider writing up an article on Dev.to about your process and the reasons why. I'm sure it'll be really useful for people.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Not being able to test intermediate (or local) builds was a problem I had earlier and I also thought that auto building would be the only way.
But, then I had a simpler idea: fork my own repo.
Now, the "published" documentation (what I want the world to see) is in my main account in the github pages doc folder of the project repo. I then created a separate, development account into which I forked the published repo. From the forked repo, I can test and publish (to another URL that I don't tell people about) as github pages automatically builds the work-in-progress docs under the development repo. When I like my changes, I send a pull request to the published repo to update it.
With that scheme, no hosting is required, no building is required, and you get instant (and manageable) documentation with no need to spin up (and manage) a server.
Yes it has some Jekyll limitations, but for the minimalist case where you don't want to manage any build or hosting servers, the tradeoffs might be worth it.
That's a good workflow you have there. You should consider writing up an article on Dev.to about your process and the reasons why. I'm sure it'll be really useful for people.