We now have integrated our Jenkins build environment hosted by
apache.org with our Ant github repo[1], such that whenever a pull
request is submitted, it now triggers a build and runs tests against the
submitted pull request and then comments/adds a status to the PR on how
the build went. This is going to help us in doing some basic
verification of the changes that's being proposed in the PR.
The job resides at [2]. Few details about this job:
1. The goal of this job is to run tests against the PR. It doesn't
produce any binaries. Furthermore, unlike the Ant Matrix builds, this
one does _not_ run against all possible combinations of JDK/OS.
2. This job has been configured to be run against Windows (for now). I
decided to use Windows since that's the one where we usually run into
issues and not many of us Ant developers are on Windows. I _might_ add
another job for the PRs which tests against Linux, but I'm not sure if
there's a easy way to do that. So for now, it's going to be just Windows.
3. This job uses Java 8 runtime to compile and run the tests,
irrespective of which branch the PR is submitted against. What this
means is even if you submit this PR against 1.9.x branch of Ant, the
minimum compatible Java version of which is Java 5, this job will still
use Java 8 to both compile and run the job. This means, it may not be
able to catch certain (compilation or other) issues. I did not find a
way to conditionally choose a JDK version for the job nor did I find a
way to conditionally choose a job for a PR (based on what branch it is
submitted). So we will have to do with this, till we support multiple
branches. However, given that this is just for basic testing and there
will be PR reviewers to actually do the review and then another round of
tests that get triggered when the PR is merged, I'm not too worried
about this constraint for now.
4. Finally, the regular Ant Matrix builds are unchanged and will
continue to build after commits are pushed to relevant branches to the
Ant upstream repo. Those jobs will remain unaffected by this change.
5. A very minor detail - I have intentionally named the job with a space
character in its name so that the checkout location too will contain
that space in the directory path (Jenkins uses the project name to
create directories for the checked out job). This will allow us to catch
certain issues we typically have with URI parsing and such. But that's
just a minor detail and doesn't have anything to do with the PR
integration itself.
The next few days, I'll probably try and see if I can get a Linux based
job to run alongside this Windows job for PRs.
One other thing - unlike the similar integration we have for Ant Ivy
job/repo, this one is much more advanced (in a good way) plugin that's
been configured with this Ant repo. This has much more finer grained
controls over what can be triggered and who can trigger/retrigger the
jobs from pull requests. This still follows the apache build conventions
and in fact uses the same technique as many other apache hosted projects
do. I'll migrate the one for Ivy to this scheme once things settle down
with this one.
[1] https://github.com/apache/ant
[2] https://builds.apache.org/job/Ant%20Github-PR-Windows/
-Jaikiran
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org
