[RTEMS Project] #2864: docs.rtems.org Automatic update of branches content when a rtems-doc.git change is made.

RTEMS trac trac at rtems.org
Tue Jan 17 05:14:41 UTC 2017


#2864: docs.rtems.org Automatic update of branches content when a rtems-doc.git
change is made.
---------------------------+-------------------
 Reporter:  chrisj         |       Owner:
     Type:  defect         |      Status:  new
 Priority:  high           |   Milestone:  4.12
Component:  Documentation  |     Version:  4.11
 Severity:  major          |  Resolution:
 Keywords:                 |
---------------------------+-------------------

Comment (by chrisj):

 Replying to [comment:5 amar]:
 > Replying to [comment:4 chrisj]:
 >
 > > Release builds are part of the release process which is a separate
 from this web site. The released documents are loaded on the the web site
 and the website's configuration updated to include the release details and
 the site is regenerated.
 >
 > They'll all be built from the same location using the same tools and
 same process the only difference is one will be a tag and the other a
 branch.  If you are talking about what 'triggers' a build then yes they
 are different.

 I am not sure if we are saying the same thing or not.

 A release of RTEMS contains released documentation and the formally
 released procedure creates that tar file of documentation. The rtems-
 release.git repo contains the format release scripts. Released
 documentation must be created as part of that formal release procedure.

 > > For building from git I was told to sort out building by cron so this
 is what I have done.
 > >
 > > Is it possible to set up a share on the TrueNAS to be a clearing house
 between sync and docs?
 >
 > How long is this going to be setup for?

 I am sorry I have no idea how long. I am just wanting to fill a gap that
 currently exists as best I can. I am after a simple, secure method to
 complete this task. As Joel says, if a simple solution can be found and
 this can be done that would be excellent. We would also be free to move on
 and sort other issues out, eg buildbot of the RTEMS code, new website, etc
 and we can come back to this when we have time, funding etc. We are
 working hard and openly to try to get this to happen but is hard.

 >  I suggested this before you mentioned building after every commit...

 I did not know sphinx could not be installed on docs.rtems.org and the
 docs built in that jail. I just assumed the docs could be built on each
 commit on docs.rtems.org. When I looked at the jail I saw you had
 installed tex alive and other packages and you had been building
 documentation there.

 >
 >
 > > > It needs to be managed properly, most projects overwrite their
 'devel' documentation with new versions.
 > >
 > > I am concerned it places extra stress on the limit resources we have
 so do not see holding builds as a priority. We have the source in git so
 someone can get that release and build it.
 >
 > Space isn't an issue it will be a decade worth of builds before it will
 be a problem.
 >
 > The other nice feature is if someone builds from a commit in source
 they'll have the corresponding documentation available that is as close to
 that version as possible -- I have a way to track this it's a tool I wrote
 some time ago.

 Sorry, I do not follow. How would someone with a local build compare and
 what would the value be in doing this?

 >
 >
 > > >  I want to keep around every single built version for comparison
 this is more useful for contributors.
 > >
 > > How is this more useful for contributors?
 >
 > Not all errors are build errors some are formatting/syntax.  Lots of
 contributors don't have the ability to build docs from source -- I don't
 think that is a pre requisit to make changes since they need to be tested
 before commit anyway.
 >
 > Docs are unique in that regard.

 We have been testing on a number of hosts and it builds ok. I have not
 built PDF on OS X as tex alive is too hard without something like brew or
 macports, HTML works.

--
Ticket URL: <http://devel.rtems.org/ticket/2864#comment:7>
RTEMS Project <http://www.rtems.org/>
RTEMS Project


More information about the bugs mailing list