[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