Closed jaredmorgs closed 8 years ago
But how do I actually go about doing that?
Whenever I ask GitHub about this, they always say the same thing. Send an e-mail to support using the contact form.
I have a vested interest in lobbying for GitHub Pages Whitelist support because I use Jekyll and GitHub Pages exclusively on my tablet, so I don't have a way of post-processing the HTML using a local CI server.
There is a way to accomplish this by leveraging a combination of CI services like Travis and GitHub webhooks, but we are missing a dedicated guide on the topic. You can find some of the essential information in @eshepelyuk's blog post: http://eshepelyuk.github.io/2014/10/28/automate-github-pages-travisci.html. All we are doing is emulating the setup that GitHub Pages is using...expect we can add whatever plugins we want ;) There's no magic happening here, though GitHub Pages definitely leaves that impression.
Here's a template:
Dear GitHub,
Would you please whitelist the jekyll-asciidoc plugin for GitHub Pages? I would love to use AsciiDoc format on GitHub Pages seamlessly.
I'd be happy to add this information to the README. Great idea!
Maybe this response should be moved back up to the asciidoctor root. I'm going to talk about my experience as a new user trying to decide between MarkDown and AsciiDoc for my Jekyll GitHub Pages blog.
I've taken a look at eshepelyuk's blog on Travis, and I'll confess I had to read it about four times before I "got it'. Furthermore, I had to jump off that page to two other pages with arguably just as much info. There's gotta be a better way of easing folks into setting this up. ;)
You're quite literally blogging in about 5 minutes tops. And not a PC in sight.
I'll concede that this is because MarkDown transformation is native, and it takes a pile of config out of the equation.
For the record, I'm not trying to blame AsciiDoc or AsciiDoctor for this, I'm just commenting as a user which approach I'd prefer.
My feeling is that if you could somehow provide an "AsciiDoc-Jekyll" repo with most of the config done or some sort of bootstrapper that folks on supported AsciiDoctor platforms could run, it would be a really easy sell. Maybe an Open Shift cartridge or something, with a start-up script that guides you through could be an option?
I know Open Shift Online lets you set up a WordPress blog in this way, so having an AsciiDoc Jekyll blog would be pretty cool to have alongside this offering, right? On Jan 16, 2015 7:39 PM, "Dan Allen" notifications@github.com wrote:
But how do I actually go about doing that?
Whenever I ask GitHub about this, they always say the same thing. Send an e-mail to support using the contact form.
I have a vested interest in lobbying for GitHub Pages Whitelist support because I use Jekyll and GitHub Pages exclusively on my tablet, so I don't have a way of post-processing the HTML using a local CI server.
There is a way to accomplish this by leveraging a combination of CI services like Travis and GitHub webhooks, but we are missing a dedicated guide on the topic. You can find some of the essential information in @eshepelyuk https://github.com/eshepelyuk's blog post: http://eshepelyuk.github.io/2014/10/28/automate-github-pages-travisci.html. All we are doing is emulating the setup that GitHub Pages is using...expect we can add whatever plugins we want ;) There's no magic happening here, though GitHub Pages definitely leaves that impression.
— Reply to this email directly or view it on GitHub https://github.com/asciidoctor/jekyll-asciidoc/issues/26#issuecomment-70229465 .
You can find some of the essential information in @eshepelyuk's blog post: http://eshepelyuk.github.io/2014/10/28/automate-github-pages-travisci.html.
I’ve used this as a starting point, but the presented script is not very good, so I wrote this rake task: https://gist.github.com/jirutka/79d5810028b994018fc2 (use rake-jekyll instead).
It’s heavily inspired by @razor-x’s blog post: Automatic publishing to GitHub Pages with Travis CI.
I’ll rewrite it as an includable library task, write some howto and send PR to this repo.
Maybe an Open Shift cartridge or something, with a start-up script that guides you through could be an option?
Wait, what? This seems like a huge overkill for such a simple thing.
A related thought this morning: Could we create a start-up project with all the necessary files and maybe some embedded instructions that people could fork to get up and running quick?
Could we create a start-up project with all the necessary files and maybe some embedded instructions that people could fork to get up and running quick?
Good idea. I've been using a local site project to test the plugin but haven't gotten around to publishing it yet. We should join forces to put a nice starting point together (which would include some of the initial polishing that normally needs to be done). If we do it, I propose we name the repository something like jekyll-asciidoc-quickstart
or something.
:+1: I can throw something together this weekend if you'd like.
Sounds great! This is exactly what the Jekyll-now repo did on the markdown side of things. Makes that initial barrier to entry much lower. On Jan 17, 2015 3:06 AM, "Dan Allen" notifications@github.com wrote:
Could we create a start-up project with all the necessary files and maybe some embedded instructions that people could fork to get up and running quick?
Good idea. I've been using a local site project to test the plugin but haven't gotten around to publishing it yet. We should join forces to put a nice starting point together (which would include some of the initial polishing that normally needs to be done). If we do it, I propose we name the repository something like jekyll-asciidoc-quickstart or something.
— Reply to this email directly or view it on GitHub https://github.com/asciidoctor/jekyll-asciidoc/issues/26#issuecomment-70285939 .
John/Dan
Thank you both for taking on this task. Folks like me that are both new to Jekyll and AsciiDoc will thank you for the effort.
If you can somehow make the repo you're collaborating on also compatible with Blender and Travis, folks that primarily wanted to author on a device other than a PC (like an Android or iOS tablet) would be well-served as well.
At a top level:
Then from this point, a user could get the same functionality as the jekyll-now repo offers except with the power of AsciiDoc:
I'd be delighted to review the instructions and test them for you guys as a "new user". On Jan 17, 2015 3:10 AM, "John Ericksen" notifications@github.com wrote:
[image: :+1:] I can throw something together this weekend if you'd like.
— Reply to this email directly or view it on GitHub https://github.com/asciidoctor/jekyll-asciidoc/issues/26#issuecomment-70286575 .
Not quite ready yet, but here's the repo: https://github.com/asciidoctor/jekyll-asciidoc-quickstart
Looks like it's coming along nicely John. Thanks for your work to get it compatible for Travis CI. On Jan 18, 2015 1:59 AM, "John Ericksen" notifications@github.com wrote:
Not quite ready yet, but here's the repo: https://github.com/asciidoctor/jekyll-asciidoc-quickstart
— Reply to this email directly or view it on GitHub https://github.com/asciidoctor/jekyll-asciidoc/issues/26#issuecomment-70372050 .
I’ll rewrite it as an includable library task, write some howto and send PR to this repo.
I eventually created a separate gem rake-jekyll with Rake tasks for Jekyll, currently just a robust task for deployment to git. I’ve already sent pull-request to jekyll-asciidoc-quickstart.
Just my 5¢. Instead of creating separate gem
containing rake
tasks, we could implement Jekyll
subcommand as described on their site directly in the current plugin.
This way jekyll-asciidoc
would be a single dependency for having all required functionality for integrating AciiDoctor
with Jekyll
.
The responsibility of jekyll-asciidoc
gem is converting of AsciiDoc pages using Asciidoctor to HTML. Deploying of a generated site using Git (or rsync, scp, FTP, pigeons…) is another task that is unrelated to AsciiDoc. That’s why I’ve packaged it as a separate gem — it can be used independently, not just with AsciiDoc and also not just with Travis or GitHub. And most importantly, without stupid copy&pasting of half-working bunch of code across projects…
This way jekyll-asciidoc would be a single dependency for having all required functionality for integrating AciiDoctor with Jekyll.
It already is. Deploying of generated sites to GitHub Pages isn’t required to integrate Asciidoctor with Jekyll. Not everyone needs to deploy Jekyll site to GitHub Pages. It’s just about adding one line to Gemfile and one line to Rakefile.
Instead of … rake tasks, we could implement Jekyll subcommand…
IMHO rake is better suited for a deployment task (more flexible).
Just my 5¢. Instead of creating separate gem containing rake tasks, we could implement Jekyll subcommand as described on their site directly in the current plugin. This way jekyll-asciidoc would be a single dependency for having all required functionality for integrating AciiDoctor with Jekyll.
It would certainly make jekyll-asciidoc attractive to GitHub if it "just worked". I'm sure it would have the effect of cutting down any perceived adoption barriers on their end.
It already is. Deploying of generated sites to GitHub Pages isn’t required to integrate Asciidoctor with Jekyll. Not everyone needs to deploy Jekyll site to GitHub Pages. It’s just about adding one line to Gemfile and one line to Rakefile.
I'm not wanting to speak for @eshepelyuk here @jirutka . If I understand @eshepelyuk's intent, he wants to make jekyll-asciidoc the solution that GitHub pages uses to transform .adoc in --safe mode, and get it whitelisted. Do other whitelisted converters have the sub-command declared? If so, I would suggest adopting the idea.
@jirutka does raise a valid point that some folks just don't need this functionality. How about an option to turn this on or off? On by default?
…he wants to make jekyll-asciidoc the solution that GitHub pages uses to transform .adoc in --safe mode, and get it whitelisted.
Once GitHub whitelists the jekyll-asciidoc plugin, then this complicated deploy task will not be needed anymore! You’ll just push pages in AsciiDoc to gh-pages branch and GitHub will generate a static site, just like with Markdown. So that’s just another reason to not copy&paste it to the plugin.
Once GitHub whitelists the jekyll-asciidoc plugin, then the current complicated deploy task will not be needed anymore! So that’s just another reason to not copy&paste it to the plugin.
OK, fair enough. Thanks for clarifying @jirutka
For the record, I've done my lobbying directly to GitHub:
Steven! Ragnarök wrote: Thanks for the suggestion Jared. I've passed it on to our Pages team to review.
Cheers, Steven!
I've also written http://jaredmorgs.github.io/whitelist-jekyll-asciidoc-for-github-pages/ and have begun sharing it widely.
Btw, I really like that we started with goals (from the blog post by @jaredmorgs)
- Fork the repo: your default blog is live!
- Make a few changes to the _config.yml file.
- Commit and Push.
- Your customized blog is live!
I wish every issue had this level of clarity. Bravo!
I also enjoy the irony of you writing blog posts in Markdown to lobby for AsciiDoc. That makes my day :)
@mojavelinux You're welcome. Red Hat has drummed into me how to "talk to developers" and raise RFEs. I write far too many of these for the Android products I beta test ;)
And, yes, writing blog posts in Markdown is exactly why I'm lobbying for AsciiDoc ;)
You might also be interested that I'm spreading this message to techy mailing lists inside Red Hat (you'd know the ones) and blogging about the initiative on the Customer Content Services blog. I'm pushing the message as far and wide as my networks allow. Let's make this happen!
The responsibility of jekyll-asciidoc gem is converting of AsciiDoc pages using Asciidoctor to HTML. Deploying of a generated site using Git (or rsync, scp, FTP, pigeons…) is another task that is unrelated to AsciiDoc.
I agree, I use jekyll-asciidoc
to generate my website and a bash script to push my website to amazon s3. I don't see how the publishing part directly relates to Asciidoc, it is more of a Jekyll compatibility thing.
You might also be interested that I'm spreading this message to techy mailing lists inside Red Hat (you'd know the ones) and blogging about the initiative on the Customer Content Services blog. I'm pushing the message as far and wide as my networks allow. Let's make this happen!
Thank you!!! That is really going to help add fuel to keep this :fire: burning strong.
Not quite ready yet, but here's the repo: https://github.com/asciidoctor/jekyll-asciidoc-quickstart
You are a champion, @johncarl81! This is going to be awesome.
I looked at my local test site and I didn't really have anything to add, other than a sample post...though it looks like you have that underway already. Proceed!
A quick update, we're rounding out the jekyll-asciidoc-quickstart project and I believe we're close to an official release. I went ahead and rebased and created a couple of sites off of this quickstart: http://androidtransfuse.org http://parceler.org http://johncarl81.github.io
I have to say, this makes the site startup a breeze.
Any feedback would be appreciated.
By the way, it looks like newlines without spaces are triggering a <br>
. Is there a setting to only do this on double newlines?
Answered my own question regarding the linebreaks. I need to read the READMEs better: https://github.com/asciidoctor/jekyll-asciidoc#hard-line-breaks
Anyone following this thread may be interested to note that GitLab Pages allows you to run Jekyll using a custom launch configuration (including the use of this plugin). In other words, you get exactly what you get on GitHub Pages, except you get to control how Jekyll is executed (no more black box). See https://about.gitlab.com/2016/04/07/gitlab-pages-setup/ for details.
Once GitHub whitelists the jekyll-asciidoc plugin, then this complicated deploy task will not be needed anymore!
Or you can just use GitLab Pages, which works exactly the same way as GitHub Pages (functionally speaking) except it gives you 100% over the build. I have document this in the README.
I think this issue is complete. We have documented all the things mentioned in this issue and the quickstart project has been established. Anything else we need to do?
Except GitLab.com (hosted instance) is slow and unreliable as hell...
Certainly the performance and reliability of GitLab have to be taken into consideration. I was speaking purely in terms of functionality.
@jirutka : You can install a runner on your local machine: See e.g. https://github.com/sboekhoff/jekyll-asciidoc-docker#use-image-for-gitlab-ci-runner . If you use Docker, it's just 2 commands to get started.
I was able to find a number of different methods to host static sites on GitLab.
https://gitlab.com/groups/pages
The concept of the GitLab Runner YML config file that lives in the repo is truly an excellent way to describe how a project builds.
Was able to set up Middleman to continuously build a site we use internally with a minimum of fuss.
On Sun, 29 May 2016 at 17:58 Dan Allen notifications@github.com wrote:
Anyone following this thread may be interested to note that GitLab Pages allows you to run Jekyll using a custom launch configuration (including the use of this plugin). In other words, you get exactly what you get on GitHub Pages, except you get to control how Jekyll is executed (no more black box). See https://about.gitlab.com/2016/04/07/gitlab-pages-setup/ for details.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/asciidoctor/jekyll-asciidoc/issues/26#issuecomment-222347930, or mute the thread https://github.com/notifications/unsubscribe/AA6J2ZEHbK8NsEA2OvJiP0ha5226wzlcks5qGUcagaJpZM4DTDr3 .
Sent from Mobile.
I scrolled down to the caveat about the plug-in not being whitelisted on GitHub Pages, and I wanted to lobby to get this plug-in added. But how do I actually go about doing that? It would be great to give terse instructions about what passionate users can do to help asciidoctor get weight behind the movement.
I have a vested interest in lobbying for GitHub Pages Whitelist support because I use Jekyll and GitHub Pages exclusively on my tablet, so I don't have a way of post-processing the HTML using a local CI server.