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