[
https://issues.jboss.org/browse/AS7-5353?page=com.atlassian.jira.plugin.s...
]
Jakub Senko updated AS7-5353:
-----------------------------
Description:
*Maven plugin to facilitate testing of local development git branches using distributed
execution on Jenkins CI.*
Currently, adding a feature or resolving a bug in large open source projects requires
several steps:
- getting the latest sources
- using tools to let the community know about the issue, such as creating a JIRA page or
assigning the developer to the issue
- when working on the problem, developer builds the code periodically after each
sub-problem is solved to see if there are no test regressions
- after the work is done, developer usually starts a pull request, after which a Jenkins
job is created and run
- and if the job is successful, the problem is marked as resolved and the JIRA page
updated
Often the developer has no access to the community Jenkins machine, or at least until the
pull request has started. But that is usually done at the final stages of development.
Using Jenkins throughout the whole process would not only take off the load from his
machine and provide a consistent testing environment, but would be very useful if there
are other contributors working on the problem. If he wants to benefit from this, he has to
set up his own Jenkins machine and manually create job(s) to run tests. However, doing
this would be a tedious work and developer might consider it too time consuming to do. If
there was a tool that could not only automate the creation of a Jenkins job, but also
execute it and retrieve back the results it could be very useful.
This can be integrated into maven as a plugin, and would cause the job to run remotely on
a specified Jenkins instance. It can also automate other tasks mentioned earlier such as
creating a development branch with a name according to name of the JIRA issue, or starting
a pull request. The information about how the Jenkins job should be created and with which
parameters it has to run can be defined directly in pom.xml of the project, and thus it
will be part of the project itself and accessible to other developers.
Apart from this main use-case, the plugin may be (after more development) useful as an
administration tool for Jenkins. The configuration of a Jenkins server could be managed as
any other community maven project. Also part of the project can be used as a Java API for
remote access to Jenkins, which can be used in other projects.
*Technical description (in progress, suggestions are welcome)*
The maven plugin currently consists of two goals:
The first goal will parse the job configuration from pom.xml a when executed, it will
create new Job on the given Jenkins instance.
Configuration to create a simple maven-based job may look as simple as:
{code:xml|title=pom.xml|borderStyle=solid}
<configuration>
<url>${jenkins.url}</url>
<jobs>
<job>
<id>test</id>
<name>test-job</name>
<scm>
<git>${git.url}</git>
</scm>
<rootPom>myapp/pom.xml</rootPom>
<ifExists>skip</ifExists>
</job>
</jobs>
</configuration>
{code}
The second goal will execute the job, and optionally performs some cleanup:
{code:xml|title=pom.xml|borderStyle=solid}
<configuration>
<url>${jenkins.url}</url>
<runs>
<run>
<id>test</id>
<name>test-${maven.build.timestamp}</name>
<results> <!-- this describes which type of results and how are
collected -->
<result>
<type>progress</type> <!-- simple progress bar is drawn
while running the build remotely -->
</result>
<result>
<type>shorttest</type> <!-- then a summary of the test
results is displayed -->
</result>
<result>
<type>shorttest</type> <!-- and it is also saved to a
file -->
<file>shorttest.txt</file>
</result>
</results>
<failLocally>true</failLocally> <!-- fail the local maven
execution when the remote Jenkins job fails -->
</run>
</runs>
</configuration>
{code}
was:
*Maven plugin to facilitate testing of local development git branches using distributed
execution on Jenkins CI.*
Currently, adding a feature or resolving a bug in large open source projects requires
several steps:
- getting the latest sources
- using tools to let the community know about the issue, such as creating a JIRA page or
assigning the developer to the issue
- when working on the problem, developer builds the code periodically after each
sub-problem is solved to see if there are no test regressions
- after the work is done, developer usually starts a pull request, after which a Jenkins
job is created and run
- and if the job is successful, the problem is marked as resolved and the JIRA page
updated
Often the developer has no access to the community Jenkins machine, or at least until the
pull request has started. But that is usually done at the final stages of development.
Using Jenkins throughout the whole process would not only take off the load from his
machine and provide a consistent testing environment, but would be very useful if there
are other contributors working on the problem. If he wants to benefit from this, he has to
set up his own Jenkins machine and manually create job(s) to run tests. However, doing
this would be a tedious work and developer might consider it too time consuming to do.
However, if there was a tool that could not only automate the creation of a Jenkins job,
but also execute it and retrieve back the results it could be very useful.
This can be integrated into maven as a plugin, and would cause the job to run remotely on
a specified Jenkins instance. It can also automate other tasks mentioned earlier such as
creating a development branch with a name according to name of the JIRA issue, or starting
a pull request. The information about how the Jenkins job should be created and with which
parameters it has to run can be defined directly in pom.xml of the project, and thus it
will be part of the project itself and accessible to other developers.
Apart from this main use-case, the plugin may be (after more development) useful as an
administration tool for Jenkins. The configuration of a Jenkins server could be managed as
any other community maven project. Also part of the project can be used as a Java API for
remote access to Jenkins, which can be used in other projects.
*Technical description (in progress, suggestions are welcome)*
The maven plugin currently consists of two goals:
The first goal will parse the job configuration from pom.xml a when executed, it will
create new Job on the given Jenkins instance.
Configuration to create a simple maven-based job may look as simple as:
{code:xml|title=pom.xml|borderStyle=solid}
<configuration>
<url>${jenkins.url}</url>
<jobs>
<job>
<id>test</id>
<name>test-job</name>
<scm>
<git>${git.url}</git>
</scm>
<rootPom>myapp/pom.xml</rootPom>
<ifExists>skip</ifExists>
</job>
</jobs>
</configuration>
{code}
The second goal will execute the job, and optionally performs some cleanup:
{code:xml|title=pom.xml|borderStyle=solid}
<configuration>
<url>${jenkins.url}</url>
<runs>
<run>
<id>test</id>
<name>test-${maven.build.timestamp}</name>
<results> <!-- this describes which type of results and how are
collected -->
<result>
<type>progress</type> <!-- simple progress bar is drawn
while running the build remotely -->
</result>
<result>
<type>shorttest</type> <!-- then a summary of the test
results is displayed -->
</result>
<result>
<type>shorttest</type> <!-- and it is also saved to a
file -->
<file>shorttest.txt</file>
</result>
</results>
<failLocally>true</failLocally> <!-- fail the local maven
execution when the remote Jenkins job fails -->
</run>
</runs>
</configuration>
{code}
TS: Maven plugin for executing testsuite asynchronously in Jenkins.
-------------------------------------------------------------------
Key: AS7-5353
URL:
https://issues.jboss.org/browse/AS7-5353
Project: Application Server 7
Issue Type: Feature Request
Reporter: Jakub Senko
Assignee: Jakub Senko
*Maven plugin to facilitate testing of local development git branches using distributed
execution on Jenkins CI.*
Currently, adding a feature or resolving a bug in large open source projects requires
several steps:
- getting the latest sources
- using tools to let the community know about the issue, such as creating a JIRA page or
assigning the developer to the issue
- when working on the problem, developer builds the code periodically after each
sub-problem is solved to see if there are no test regressions
- after the work is done, developer usually starts a pull request, after which a Jenkins
job is created and run
- and if the job is successful, the problem is marked as resolved and the JIRA page
updated
Often the developer has no access to the community Jenkins machine, or at least until the
pull request has started. But that is usually done at the final stages of development.
Using Jenkins throughout the whole process would not only take off the load from his
machine and provide a consistent testing environment, but would be very useful if there
are other contributors working on the problem. If he wants to benefit from this, he has to
set up his own Jenkins machine and manually create job(s) to run tests. However, doing
this would be a tedious work and developer might consider it too time consuming to do. If
there was a tool that could not only automate the creation of a Jenkins job, but also
execute it and retrieve back the results it could be very useful.
This can be integrated into maven as a plugin, and would cause the job to run remotely on
a specified Jenkins instance. It can also automate other tasks mentioned earlier such as
creating a development branch with a name according to name of the JIRA issue, or starting
a pull request. The information about how the Jenkins job should be created and with which
parameters it has to run can be defined directly in pom.xml of the project, and thus it
will be part of the project itself and accessible to other developers.
Apart from this main use-case, the plugin may be (after more development) useful as an
administration tool for Jenkins. The configuration of a Jenkins server could be managed as
any other community maven project. Also part of the project can be used as a Java API for
remote access to Jenkins, which can be used in other projects.
*Technical description (in progress, suggestions are welcome)*
The maven plugin currently consists of two goals:
The first goal will parse the job configuration from pom.xml a when executed, it will
create new Job on the given Jenkins instance.
Configuration to create a simple maven-based job may look as simple as:
{code:xml|title=pom.xml|borderStyle=solid}
<configuration>
<url>${jenkins.url}</url>
<jobs>
<job>
<id>test</id>
<name>test-job</name>
<scm>
<git>${git.url}</git>
</scm>
<rootPom>myapp/pom.xml</rootPom>
<ifExists>skip</ifExists>
</job>
</jobs>
</configuration>
{code}
The second goal will execute the job, and optionally performs some cleanup:
{code:xml|title=pom.xml|borderStyle=solid}
<configuration>
<url>${jenkins.url}</url>
<runs>
<run>
<id>test</id>
<name>test-${maven.build.timestamp}</name>
<results> <!-- this describes which type of results and how are
collected -->
<result>
<type>progress</type> <!-- simple progress bar is drawn
while running the build remotely -->
</result>
<result>
<type>shorttest</type> <!-- then a summary of the test
results is displayed -->
</result>
<result>
<type>shorttest</type> <!-- and it is also saved to a
file -->
<file>shorttest.txt</file>
</result>
</results>
<failLocally>true</failLocally> <!-- fail the local maven
execution when the remote Jenkins job fails -->
</run>
</runs>
</configuration>
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:
http://www.atlassian.com/software/jira