[
https://issues.apache.org/jira/browse/APEXCORE-526?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15690911#comment-15690911
]
Munagala V. Ramanath edited comment on APEXCORE-526 at 11/23/16 6:09 PM:
-------------------------------------------------------------------------
Anything that can be generated with a sequence of shell commands can be added.
The Python code (and hence the documentation for it) can change as we add more
branches and features but here is a quick summary of the current state:
*Buildbot* is a Python-based tool CI tool. Build services using buildbot are
available
on Apache infrastructure with some very basic documentation at
[https://ci.apache.org/buildbot.html]
Included on that page are various links to view the status of recent builds.
Buildbot is configured via configuration files with the *{{.conf}}* extension;
these files
are not just key-value pairs but rather full Python scripts.
The configuration file for Apache projects are in an SVN repo at:
[https://svn.apache.org/repos/infra/infrastructure/buildbot/aegis/buildmaster/master1/projects]
There are files for around 70 projects and looking at those files is a good way
to figure out how to setup a build.
The Apex build is in *{{apex.conf}}*. All configuration files are catenated
together before
execution, so we need to be mindful of potential name clashes. The result of
running the
configuration file should be to append suitable objects to the global map named
simply *{{c}}*.
Commonly, we create and append a builder object to *{{c['builders']}}* and a
scheduler object to
*{{c['schedulers']}}*.
A builder is just a key-value map containing things like the builder name, list
of slaves
to run the build on, environment variable settings and, most importantly, a
*BuildFactory*
which holds the various steps of the build.
In the Apex case, we define a function named *{{add_apex_malhar_builders()}}*
and invoke it;
this minimizes the likelihood of global name clashes. We create a build factory
containing
these steps:
{quote}
(a) Run git to checkout desired branch.
(b) Run mvn to generate the javadocs.
(c) Cleanup tmp directory.
(d) Upload files to master.
(e) Publish files to appropriate directory on master.
(f) Cleanup tmp directory again.
{quote}
We explicitly set *JAVA_HOME* to point to 1.8 to avoid some build problems.
This path
is not uniform on all the slaves and causes the build to fail sometimes
depending
on which slave it runs on; a fix is pending.
We add a single scheduler which schedules a build every 24hrs.
Once the *{{apex.conf}}* file is checked back in to the SVN repository after
making changes
it should take effect a few minutes later.
was (Author: dtram):
Anything that can be generated with a sequence of shell commands can be added.
The Python code (and hence the documentation for it) can change as we add more
branches and features but here is a quick summary of the current state:
*Buildbot* is a Python-based tool CI tool. Build services using buildbot are
available
on Apache infrastructure with some very basic documentation at
[https://ci.apache.org/buildbot.html]
Included on that page are various links to view the status of recent builds.
Buildbot is configured via configuration files with the *{{.conf}}* extension;
these files
are not just key-value pairs but rather full Python scripts.
The configuration file for Apache projects are in an SVN repo at:
[https://svn.apache.org/repos/infra/infrastructure/buildbot/aegis/buildmaster/master1/projects]
There are files for around 70 projects and looking at those files is a good way
to figure out how to setup a build.
The Apex build is in *{{apex.conf}}*. All configuration files are catenated
together before
execution, so we need to be mindful of potential name clashes. The result of
running the
configuration file should be to append suitable objects to the global map named
simply *{{c}}*.
Commonly, we create and append a builder object to *{{c['builders']}}* and a
scheduler object to
*{{c['schedulers']}}*.
A builder is just a key-value map containing things like the builder name, list
of slaves
to run the build on, environment variable settings and, most importantly, a
*BuildFactory*
which holds the various steps of the build.
In the Apex case, we define a function named *{{add_apex_malhar_builders()}}*
and invoke it;
this minimizes the likelihood of global name clashes. We create a build factory
containing
these steps:
{quote}
(a) Run git to checkout desired branch.
(b) Run mvn to generate the javadocs.
(c) Cleanup tmp directory.
(d) Upload files to master.
(e) Publish files to appropriate directory on master.
(f) Cleanup tmp directory again.
We explicitly set *JAVA_HOME* to point to 1.8 to avoid some build problems.
This path
is not uniform on all the slaves and causes the build to fail sometimes
depending
on which slave it runs on; a fix is pending.
We add a single scheduler which schedules a build every 24hrs.
Once the *{{apex.conf}}* file is checked back in to the SVN repository after
making changes
it should take effect a few minutes later.
> Publish javadoc for releases on ASF infrastructure
> ---------------------------------------------------
>
> Key: APEXCORE-526
> URL: https://issues.apache.org/jira/browse/APEXCORE-526
> Project: Apache Apex Core
> Issue Type: Documentation
> Reporter: Thomas Weise
>
> Every release should have the javadocs published and we should have it linked
> from the download page, as is the case with user docs.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
