> On 5. Sep 2019, at 16:28, Stefan Seifert <sseif...@pro-vision.de> 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 This is now tracked in https://issues.apache.org/jira/browse/SLING-8704 <https://issues.apache.org/jira/browse/SLING-8704>.
> > - 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) > > - 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 > > - 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 > > - 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 > > - 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 > > Stefan > >
