I will begin to implement the pre-tested commit feature
This features is very requested.

I will providing details on the operating mechanism.
Your feedback on this need or your suggestions
will be appreciate.

Issue started

That will be great!

i am very interested in that feature.

if you need (pre-)tester of an beta of this feature we could probably help.

.

Hi all,

Any update in this feature? It was marked as STARTED in November 2008, but it
looks like no progress have been made so far...

– Felipe

Hello,

You are right, this issue was started since a long time.
I spent some days on it at end of December.
And since the beginning of the year, I had others priorities on Hudson. For
instance the improvement of integration of the SCM clearcase, the support of
C/C++ and Ada languages implemented with the doxygen, gnat, cppunit, cccc,
scons. And It took more time than expected.
But the pre-test commit feature is very important and very expected.

For this feature, we must analysed the priorities
Which first IDE support : Eclipse or IDEA support?
Which first SCM support : SVN firt, Clearcase, ….

At the moment, I have some advanced scripts for the pre tested commit feature
with Clearcase UCM.
I plan to migrate my scripts in a Java program for integrating them with Hudson
and the Eclipse Clearcase plugin.

For SVN, I have analyzed the TeamCity workflow.
TeamCity creates a SVN patch containing the developer change set.
Then, this patch is posted to the CI server that receives the path and applies
the patch to the latest modifications. Then the build is launched.
The developer receives the build status and if there is a success build, the
developer can commit the tested change set.
For the Eclipse integration. TeamCity is based on Subeclipse. But it seems
Subversive is a good challenger. So, we must choose the best plugin.

The main idea is to reuse the same Teamcity workflow.
I started with scripts to implement this scenario for Subversion and Hudson. The
implementation uses the Hudson Remote API.

And I must begin to provide a full integrating with Hudson.

If we can split the work, any help will be appreciate?

Hi all,

Any update in this feature?

If you need some help in coding/testing of this feature my team could probably help.

This is a feature that I too would very much appreciate. Too often we get email saying "trunk is broken,
don't checkout until fixed." I think this feature would greatly reduce that problem.

I wonder if we can break up the work into a number of areas:

1) Shared server-side support for receiving and queuing changes to be tested (which might be diffs in a
shared format, diffs in an scm product format, or might be whole files, based on file type and tooling
needs/abilities). We might expose a url like:

http://host/hudson/job/job-name/changes-to-test

The client would POST a file (e.g. a patch) to that url, with appropriate security checks applied upon
receipt to decide whether or not to queue the changes to be tested. Presumably we could allow a GET on that
address to return the queue of changes to be tested.

We might also want to provide a web page (per job) that permits a user to upload changes (so limited client-
side work is required).

2) Shared server-side support for applying changes to a workspace (for the shared-format diffs and whole
files). If the changes couldn't be applied, then the we'd probably want to send an email back to the user
reporting the problem. We might want to do a trial apply when the changes are posted, to ensure that any

3) Extensions to the SCM API to indicate level of support for pre-tested commit (e.g. might be able to test
the changes, but not commit them to the scm system).

4) Extensions to the SCM API to support applying changes (for the proprietary diff format case). In the
case of Perforce or ClearCase, this would involve at least checking out the file before saving the modified
file.

5) Extensions to the SCM API to support committing changes upon a successful build (and sending an email),
or reverting the files if the build fails.

6) Client-side tooling (IDE integrations, or CLI) for creating and uploading the collection of changes to be
tested, presumably based on info from the client's scm system regarding the changed files.

Adding myself to cc list.

I wrote a Wiki page to hash out various ideas of how to implement this feature
at http://wiki.hudson-ci.org/display/HUDSON/Designing+pre-tested+commit

Feedback and comments are appreciated.

Please, please make a command line client first and then do integrations to IDEs.
This way everyone would benefit, and this command line client could be a base
for plugins to IDE.

A command-line interface, or client-side Java API sound like an excellent idea.
Perhaps even before that, a REST API implemented by the server to enable a client
to create a short-lived (e.g. hours, not one ) thing on disk that represents the
change(s) to be tested, and another such API to trigger a build using those
changes.

add myself to the cc so I can follow news on that eagerly awaited feature

• • • Issue 1365 has been marked as a duplicate of this issue. ***

+1 vote. This is an excellent feature!