I'm currently using poll SCM every 30 minutes to cover master and
EE4J_8 branches. It seems to be enough with current frequency of
changes in our projects. Triggering by GitHub events (hooks) will
be better, but we can live without that now.
For the beginning it would be good to start with continuous build
for master and EE4J_8 branches and with release job that can work
with any branch.
https://github.com/orgs/eclipse-ee4j/projects/1#card-13284080
still contains a very long list of unfinished tasks so let's
concentrate on this minimal set for each of the projects.
After that it would be nice to do few more things:
- build for PRs - here we will have to rely on some GitHub hooks
and related plugin, or use for example Travis
I already saw broken builds few times so incoming PRs
need some build and test coverage (and also some formal checks
like headers, coding style, findbugs, etc.) as part of review
process
- use maven nexus plugin to close staging deployments in release
job
But those things are not highest priority tasks now.
Tomas
Dne 09/10/18 v 12:13 Tom Jenkinson
napsal(a):
Just to mention that Bill is looking to monitor for
mainline branch repo changes I think (e.g. master/EE4j_8) -
rather than PR. Or at least that is how I interpretted it.
_______________________________________________
ee4j-build mailing list
ee4j-build@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/ee4j-build