accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher <ctubb...@apache.org>
Subject Re: git-based site and jekyll
Date Sun, 13 Mar 2016 05:25:25 GMT
Well, if I wasn't a git aficionado before, I'm well on my way. Using some
low-level git commands (making full use of StackOverflow[1]), I actually
put together a git post-commit hook to automatically regenerate and update
the accumulo.apache.org branch (assuming you have one checked out locally)
whenever you edit the gh-pages branch.

Feel free to check it out here[2]. I've gone ahead and checked it into the
gh-pages repo in a "hidden" (from Jekyll) developer area.

Basically, if you have a local branch (hopefully one that is up-to-date and
tracking upstream accumulo git) called "accumulo.apache.org", and you're
current working branch is "gh-pages", all you need to do is copy (or
symlink) the file to .git/hooks/post-commit

This is just one useful way to automate this. A pre-push hook might work
just as well, which commits directly to the remote or something which
doesn't require a local up-to-date tracking branch to be useful. Still, I'm
pretty proud of it.

Enjoy!

[1]: http://stackoverflow.com/a/35963533/196405
[2]:
https://github.com/apache/accumulo/blob/gh-pages/_devtools/git-hooks/post-commit


On Fri, Mar 11, 2016 at 1:12 PM Josh Elser <josh.elser@gmail.com> wrote:

> +1
>
> Dylan Hutchison wrote:
> > Sounds great Chris!
> >
> > On Fri, Mar 11, 2016 at 9:50 AM, Christopher<ctubbsii@apache.org>
> wrote:
> >
> >> So, if everybody's happy doing this, I'll go ahead and perform the
> >> following steps:
> >>
> >> 1. Push gh-pages branch to our repo
> >> 2. Perform a jekyll build on the branch and put it in a branch called "
> >> accumulo.apache.org"
> >> 3. Push the accumulo.apache.org branch
> >> 4. File INFRA ticket to switch our site to git using the
> >> accumulo.apache.org
> >> branch
> >>
> >>
> >> On Fri, Mar 11, 2016 at 11:46 AM Billie Rinaldi<
> billie.rinaldi@gmail.com>
> >> wrote:
> >>
> >>> Wow, that's looking great.  Thanks, Christopher!
> >>>
> >>> Billie
> >>>
> >>> On Thu, Mar 10, 2016 at 10:38 PM, Christopher<ctubbsii@apache.org>
> >> wrote:
> >>>> Thanks Josh! I fixed all the issues you saw, except the screenshots
> >> one,
> >>>> since that's currently just how our layout is (looks the same at
> >>>> accumulo.apache.org).
> >>>>
> >>>> Most of the bugs you saw were existing bugs with either our HTML or
> our
> >>>> Markdown... but whatever CMS is doing is a bit more tolerant than
> >>> Kramdown
> >>>> is apparently.
> >>>>
> >>>> Biggest problem I saw was that people keep forgetting quotes around
> >> HTML
> >>>> attributes. Example, it should be<a href="location">, not<a
> >>>> href=location>.
> >>>>
> >>>> On Thu, Mar 10, 2016 at 9:57 PM Josh Elser<josh.elser@gmail.com>
> >> wrote:
> >>>>> * Some companies on http://ctubbsii.github.io/accumulo/people.html
> >> are
> >>>>> goofed as are the timezones.
> >>>>> * Some broken links on
> >> http://ctubbsii.github.io/accumulo/source.html.
> >>>>> Coding practices are also messed up.
> >>>>> * http://ctubbsii.github.io/accumulo/contrib.html contrib project
> >>>>> entries are a little wacky.
> >>>>> * http://ctubbsii.github.io/accumulo/screenshots.html is weird with
> >>> the
> >>>>> monitor screenshot (should be beneath the text?)
> >>>>> * Just noticed that Other and Documentation both have a link to
the
> >>>>> papers/presentations. That might actually be how the site is now,
> >> just
> >>>>> realized it's duplicative.
> >>>>>
> >>>>> Thanks again for doing this. It's great!
> >>>>>
> >>>>> Christopher wrote:
> >>>>>> Actually, I now have it all working (as far as I can tell) with
> >>>>> everything
> >>>>>> pretty much the same as it looks with CMS today. After people
have
> >>>> taken
> >>>>>> the time to give it a glance, I'll push it to the ASF repo,
and
> >> then
> >>>> push
> >>>>>> the generated site to a separate branch. Then we can put in
the
> >> INFRA
> >>>>>> ticket to switch from svn to git.
> >>>>>>
> >>>>>> On Thu, Mar 10, 2016 at 6:42 PM Christopher<ctubbsii@apache.org>
> >>>> wrote:
> >>>>>>> I'm working on converting our current site contents over
to jekyll
> >>> at
> >>>>>>> https://github.com/ctubbsii/accumulo/tree/gh-pages
> >>>>>>> (view at http://ctubbsii.github.io/accumulo)
> >>>>>>>
> >>>>>>> Yes, it's terrible right now... it's in progress. :)
> >>>>>>>
> >>>>>>> On Tue, Mar 8, 2016 at 4:21 PM Josh Elser<josh.elser@gmail.com>
> >>>> wrote:
> >>>>>>>> Lazy consensus is fine. If there are no objections,
I don't want
> >> to
> >>>>> hold
> >>>>>>>> things up. I feel like I've adequately expressed my
concerns.
> >>> Silence
> >>>>>>>> can and should be treated as acknowledgement for this,
IMO.
> >>>>>>>>
> >>>>>>>> Christopher wrote:
> >>>>>>>>> Another reason we probably shouldn't worry about
this: anybody
> >> can
> >>>>>>>> create a
> >>>>>>>>> DNS name at their leisure which transparently redirects
to
> >>>>>>>>> accumulo.apache.org and serves its contents. This
is perfectly
> >>>>>>>> legitimate
> >>>>>>>>> for a number of reasons, including corporate proxies/mirrors,
> >>>>>>>>> URL-shortening services, caching services, archiving
services,
> >>>>>>>>> vision-impaired accessibility services, foreign-language
DNS
> >>>> mappings,
> >>>>>>>> and
> >>>>>>>>> so-on.
> >>>>>>>>>
> >>>>>>>>> I think when it comes to trademarks and our website,
our area of
> >>>>> concern
> >>>>>>>>> should mostly focus on when people misrepresent
our trademark in
> >>> the
> >>>>>>>> course
> >>>>>>>>> of their mirroring/archiving. There's no risk of
that for a
> >> mirror
> >>>>> that
> >>>>>>>> is
> >>>>>>>>> explicitly under our control, but I'm really leaning
towards the
> >>>>>>>> javascript
> >>>>>>>>> to detect and display a message about the canonical
location
> >> just
> >>> to
> >>>>>>>>> mitigate any possibility for concern.
> >>>>>>>>>
> >>>>>>>>> If you still have concerns, I'd be happy to put
it up for a
> >> formal
> >>>>> vote
> >>>>>>>>> from the PMC, or to get feedback from ASF trademarks
folks
> >> before
> >>> we
> >>>>>>>>> proceed.
> >>>>>>>>>
> >>>>>>>>> On Tue, Mar 8, 2016 at 3:22 PM Josh Elser<josh.elser@gmail.com>
> >>>>>   wrote:
> >>>>>>>>>> Well, I think the difference is that archive.org
(and others
> >> --
> >>>>> google
> >>>>>>>>>> cached pages come to mind) are devoted/known
for that specific
> >>>>> purpose.
> >>>>>>>>>> The fact that Github ends up being a "de-facto"
location for
> >>>> software
> >>>>>>>>>> projects, I'm just nervous about the expecting
good faith from
> >>> the
> >>>>>>>>>> denizens of the internet. Maybe I'm just worrying
too much. If
> >>>>> there's
> >>>>>>>>>> sufficient "it'll be ok" opinion coming from
the PMC, it's fine
> >>> by
> >>>>> me.
> >>>>>>>>>> Christopher wrote:
> >>>>>>>>>>> I can't imagine there's a trademark issue
since it's really
> >> just
> >>>>>>>> acting
> >>>>>>>>>> as
> >>>>>>>>>>> a mirror. If there were trademark issues,
I imagine sites like
> >>>>>>>>>>> http://archive.org would be in big trouble.
But, it certainly
> >>>>>>>> couldn't
> >>>>>>>>>> hurt
> >>>>>>>>>>> to find out.
> >>>>>>>>>>>
> >>>>>>>>>>> Another option to sabotage the GH-rendered
site is to add some
> >>>>>>>> javascript
> >>>>>>>>>>> which detects the location and displays
an informative link
> >> back
> >>>> to
> >>>>>>>> the
> >>>>>>>>>>> canonical location for the site. That should
be simple enough
> >> to
> >>>> do.
> >>>>>>>>>>> On Tue, Mar 8, 2016 at 1:36 PM Josh Elser<
> >> josh.elser@gmail.com>
> >>>>>>>>    wrote:
> >>>>>>>>>>>> It's also probably worth mentioning
that this concern only
> >>> comes
> >>>>>>>> about
> >>>>>>>>>>>> for point #4 (or if we use the branch
name gh-pages in point
> >>> #1).
> >>>>>>>>>>>> Josh Elser wrote:
> >>>>>>>>>>>>> The one concern I had was regarding
automatic rendering of
> >>> what
> >>>>>>>> would
> >>>>>>>>>>>>> look like "the Apache Accumulo website"
on Github (both
> >>>>>>>> apache/accumulo
> >>>>>>>>>>>>> github account and other forks).
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Christopher had said that no one
seemed to object in comdev@
> >>>> when
> >>>>>>>> he
> >>>>>>>>>>>>> talked about this a while back.
I wanted to make sure
> >> everyone
> >>>>>>>>>>>>> considered this (for example, Christopher's
fork of Drill's
> >>>>>>>> repository
> >>>>>>>>>>>>> now also looks like a canonical
host of the Apache Drill
> >>>> project).
> >>>>>>>> I'm
> >>>>>>>>>>>>> not actively stating that I think
it's an issue at this
> >> point,
> >>>>> only
> >>>>>>>>>>>>> suggesting that we give it some
thought and maybe ask
> >> someone
> >>>> who
> >>>>> is
> >>>>>>>>>>>>> more knowledgable (Shane from trademarks?)
before moving
> >>>> forward.
> >>>>>>>> The
> >>>>>>>>>>>>> worst case I envision is that we
find some way to "gimp" the
> >>>>>>>>>>>>> github-rendered site (redirect back
to the canonical
> >>>>>>>>>> accumulo.apache.org
> >>>>>>>>>>>>> or similar).
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Christopher wrote:
> >>>>>>>>>>>>>> I got some information back
from INFRA about how the
> >>> git-based
> >>>>>>>> sites
> >>>>>>>>>>>>>> work.
> >>>>>>>>>>>>>> It's just plain old static hosting
of a git branch. So,
> >>>> whatever
> >>>>>>>> we'd
> >>>>>>>>>>>> put
> >>>>>>>>>>>>>> in a specified branch would
show up directly on the site,
> >> no
> >>>>>>>> rendering
> >>>>>>>>>>>> or
> >>>>>>>>>>>>>> generation. This would completely
bypass CMS and buildbot
> >>>> staging
> >>>>>>>>>>>> builds.
> >>>>>>>>>>>>>> Was discussing this with elserj
in IRC, and these ideas
> >> came
> >>>> out
> >>>>> of
> >>>>>>>>>>>> that:
> >>>>>>>>>>>>>> 1. Switch site to use git branch
named "site" or "website"
> >> or
> >>>>>>>> similar.
> >>>>>>>>>>>>>> 2. Use jekyll 3 to generate
the static site contents in
> >> this
> >>>> git
> >>>>>>>>>> branch.
> >>>>>>>>>>>>>> 3. Store the unrendered (markdown)
jekyll stuff in a
> >> gh-pages
> >>>>>>>> branch.
> >>>>>>>>>>>>>> 4. Possibly set up a post-commit
hook on gh-pages branch to
> >>>>> render
> >>>>>>>>>>>>>> locally
> >>>>>>>>>>>>>> and commit the generated static
site to the "site" branch.
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message