The command line is still needed for local testing even if using GitHub pages.
You're right about the hosting. They provide it for free.
The only limitation is that with GitHub pages, Jekyll plugins are not available so if you're relying on any of these you'll have to host yourself else where.
Luckily though, I've also written an article about how to automate the build and deploy of a Jekyll site to any FTP host using Travis CI.
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.
The command line is still needed for local testing even if using GitHub pages.
You're right about the hosting. They provide it for free.
The only limitation is that with GitHub pages, Jekyll plugins are not available so if you're relying on any of these you'll have to host yourself else where.
Luckily though, I've also written an article about how to automate the build and deploy of a Jekyll site to any FTP host using Travis CI.
ajaykarwal.com/deploying-jekyll-us...
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.