0

I really like Hudson but I do not see a way to handle a quick succession of checkins. The idea is that every checkin gets a smoke test run against and if change number 1234's regression does not finish before checkin 1235 and 1236 how is that supposed to be handled? Is up to an external script to keep track of which changelists have been run or does Hudson keep track of this for you? I tried to look through the documentation to see how this is handled but I couldn't find anything.

Let me know if my question needs clarification.

stephenmm
  • 2,640
  • 3
  • 30
  • 48

2 Answers2

1

You can create parameterized build (e.g. SMOKE_TEST) that will take revision number as input parameter (e.g. REVISION_NUMBER). Of course, checkout should be implemented as one of the build steps (not as trigger):

BUILD STEPS:

  1. Check out needed revision based on the build parameter REVISION_NUMBER
  2. Run smoke test

Then implement another job (e.g. REVISION_CONTROLLER) that will monitor source control repository for new revisions. As soon as new revision is found the job starts SMOKE_TEST instance with new revision as a parameter using Hudson HTTP URL of SMOKE_TEST job like: http://server/job/SMOKE_TEST/buildWithParameters?REVISION_NUMBER=...

All instances of the SMOKE_TEST will be put in the queue and thus if 1234 is not finished, 1235 will wait for that. Also you have a chance to start a smoke test for custom revision in case you want to rerun it.

Andrey Adamovich
  • 20,285
  • 14
  • 94
  • 132
0

A practical approach:

  • Make a first job as short as possible, and let it trigger a longer job afterwards if you must (f.ex. consider goals compile vs install in Maven)
  • If the quick job takes 2 minutes, let it poll the SCM every 2 minutes

This won't guarantee a compilation ("smoke") for every commit, but close. And Hudson/ Jenkins keeps track of changes for you - see the "Changes" menu item on the job page, and the "Changes" menu item on each build page.

Ingvald
  • 443
  • 1
  • 4
  • 12