- 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)
- 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
