[
https://issues.apache.org/jira/browse/SOLR-10568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15985388#comment-15985388
]
Cassandra Targett commented on SOLR-10568:
------------------------------------------
I didn't explain it all very well in my initial description, maybe. I filed
this to discuss some of what Jan proposed in his dream scenario:
https://issues.apache.org/jira/browse/SOLR-10295?focusedCommentId=15930934&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15930934
{quote}
I would fully automate the build and publishing of the various versions of the
HTML ref-guide though a new bot. The bot would watch git commits, build the
HTML guide and publish it.
I think {{http://lucene.apache.org/solr/guide/}} would be a great landing page
for the guide. It would be a page highlighting the latest official released
guide, as well as linking to historic versions and also, less prominently,
unreleased versions, such as master, branch_6x, branch_6_4 etc. This landing
page could even be an SPA with auto generated links based on info we already
have in [DOAP|https://projects.apache.org/json/projects/lucene-core.json] and
git. So we would have
{noformat}
http://lucene.apache.org/solr/guide/ (main landing page)
http://lucene.apache.org/solr/guide/6_5/ (built from branch_6_5, this way we
can release bugfixes simply by committing to the branch)
http://lucene.apache.org/solr/guide/branch_6x/ (build from branch_6x, next
feature version to be released)
http://lucene.apache.org/solr/guide/master/ (build from master, next major
version to be released)
http://lucene.apache.org/solr/guide/7_0/ (the permlink for Solr7 once it is
released)
...
{noformat}
So the bot (some script we write but Infra hosts) will
# monitor every lucene-solr git commit
# if branch in not master, or a release branch, or if commit does not modify
refguide, then exit
# checkout the branch
# build ref-guide using ant, jekyll etc
# publish the resulting guide to the website under correct sub folder (see
above).
#* Alternatively, publish to some other place such as www.solr-guide.com or
wherever we want really.
# if JIRA issue mentioned in commit message, also add a comment to the JIRA
issue with a link to the newly built version of the guide.
#* Could even generate a list of deep-links to the individual guide pages
changed by the commit, for easier review.
# if the build of the refguide fails, then post to the JIRA issue a relevant
error message
{quote}
This led to the discussion in SOLR-10295 about gitsubpub, to automate building
on every commit and publishing.
> Automate HTML builds via Jenkins to occur with each commit
> ----------------------------------------------------------
>
> Key: SOLR-10568
> URL: https://issues.apache.org/jira/browse/SOLR-10568
> Project: Solr
> Issue Type: Sub-task
> Security Level: Public(Default Security Level. Issues are Public)
> Components: documentation
> Reporter: Cassandra Targett
> Priority: Minor
>
> Spin-off from SOLR-10295.
> The idea is to use a mechanism (possibly gitpubsub and/or svnpubsub?) so
> Jenkins builds of HTML format of the Ref Guide occur as soon as commits are
> made to any non-released branch.
> This would allow any committer to see doc changes ASAP after a commit to
> verify the presentation of the information is as expected.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
