On Thu, 2019-09-05 at 14:28 +0000, Stefan Seifert wrote:
> - Challenge: Building non-committer PRs with Jenkins is no longer
> allowed 
>   - problem described in SLING-7245 - Validate pull requests using
> Jenkins Resolved
>     - reason are security issues, see also INFRA-18973
>     - we assume it will not be fixed by INFRA due to this, we need
> another solution
>   - possible solutions in ASF Jenkins:
>     - run builds in container?
>     - use our own build slaves somewhere external?
>   - or use external CI providers like travis, cloudbees, circleci
>     - requirements for such an external CI:
>       - possibility to reuse our shared jenkins libraries to avoid
> duplication in all build descriptor files
>       - sonarcloud trigger
>     - konrad will do a PoC with cloudbees
> - sonarcube rules
>   - how can we define custom rules? (disabling default ones, add new
> ones)
>   - can we maintain those in a separate rule file (e.g. to be also
> reused outside sling)?
>   - let's start with a minimal set of custom rules
>   - auto-checking in PRs is only done for new code introduced in the
> PR
>   - all already onboarded projects need to be mapped with the new
> rule settings
>   - new projects need to be assigned manually to it (no API for it
> currently)


(volunteers welcome)

> - sonar check onbaording for new sling modules currently depends on
> contacting someone in sonarcloud to do it manually
>   - there is a user group "sling-admins" at sonarcube which can do a
> lot of things - but not onboarding new projects
>   - manual process usually takes ~2 days, sometimes longer if the
> person is not in office
>   - is there an API for this in sonarcloud that sonarcloud itself
> could use to automate the process?
>   - maybe the newly introduced "sling" topic on git repo may help?
>   - on the long run it would be nice to control something like this
> via the asf.yaml


(assigned to me)

> - git PR policies
>   - we should document our preferred way of applying PRs
>   - preferred is rebasing to get a linear history
>   - original author info should be kept in commit
>   - if squashing is required it should be done before rebasing
>   - is it possible to prevent force-push on master branch? currently
> only possible by contacting INFRA


> - sling starter
>   - already documented in release management rules: sling starter
> needs to be update with latest versions once a module contained there
> gets a new release (should be tested with sling starter before
> starting the release)
>   - all modules that are part of the sling starter: automatically run
> starter ITs for github PRs on this module


(unassigned, probably should wait until we migrate to the feature

> - website source code list
>   - add link to sling-aggregator/docs/modules page
> - Docker Engine on build hosts for integration tests (possible?)
>   - should be possible with adding additional "docker" label in the
> sling modules list -> then it gets configured in the jenkins jobs

Someone (I forget who, sorry), mentioned that all 'ubuntu' slaves have
docker installed, so this is done.

> - matrix build (e.g. multiple JDKs)
>   - can be configured already
>   - a good target list would be the java LTS versions since java 8 +
> the current unstable, e.g. 8,11,13 currently


Note that currently many of our modules do not build on Java 11, due to
using older versions of the sling parent pom. Migration is difficult
since we need to migrate away from the Felix SCR plugin.


Reply via email to