Status: Closed (View Workflow)
If a PR is not trusted and has a Jenkinsfile but the target branch of the PR does not have a Jenkinsfile, we should not report that as a PR matching the Jenkinsfile criteria as the Jenkinsfile should be sourced from the trusted revision (where there is none)
The current behaviour is that the PR will be flagged as matching the criteria and hence a build attempt will be started, but as the trusted revision does not have the Jenkinsfile the build will fail.
We should never even try to build in the first case for such an untrusted PR
- is related to
JENKINS-41561 Pullrequest github executes Jenkinsfile of origin branch
- links to
I think it is fine for the build to fail. Indeed arguably SCMBinder should always fail when the trusted Jenkinsfile differs from the untrusted one, rather than print a message and continue with a different script. ReadTrustedStep already has that stricter behavior.
Code changed in jenkins
User: Stephen Connolly
[FIXED JENKINS-41616] Non-trusted pull requests should use a probe against the trusted revision not the PR's revision