Add support for building on Jenkins. (#4159) - #4180
Conversation
Add support for building on internal Jenkins. Jenkins has been configured to build every branch on xamarin/xamarin-macios that contains a `jenkins/Jenkinsfile`, which means it will start working as soon as this PR is merged. Results will be posted as statuses on each commit, which can be viewed using the url `https://github.com/xamarin/xamarin-macios/commits/<branch>`:  * The `continuous-integration/jenkins/branch` status links to the jenkins job. * The other two are XI and XM packages (the `Jenkins-` prefix will be removed once we officially switch from Wrench to Jenkins). More detailed information will be added as a comment to each commit, which can be seen by clicking on the commit and scrolling to the bottom (url of the format `https://github.com/xamarin/xamarin-macios/commit/<sha1>`)  Unfortunately GitHub does not display the commit statuses when viewing a single commit, so to view those statuses you'll have to view the list of commits (the `/commits/` url). Tip: it's possible to use `<sha1>` instead of `<branch>` (and vice versa for that matter) if you're interested in the statuses of a particular commit. Pull requests will also be built (only from contributors with write access), but by default nothing will be done (the job will exit immediately, although a green check mark will still show up). Jenkins will **not** add a comment in the pull request in this case. However, if the label `build-package` [1] is set for a pull request, the internal jenkins job will run (it will do everything except the local xharness test run: this includes creating and publishing packages, creating various diffs, run tests on older macOS versions, test docs, etc). A detailed comment will also be added to the pull request (see below for multiple examples), which means that there will be two Jenkins comments: one for the public Jenkins which builds every PR, and one for the internal Jenkins [2]. [1] I don't quite like the name of the label, because it doesn't get even close to explain all that will actually happen, but `run-on-internal-jenkins-and-create-package` is a bit too long IMHO... Also it's non-obvious that this is the label to apply if the reason for executing on the internal jenkins is some other reason (for instance to test a maccore bump). Other ideas: * `run-internal-jenkins`: doesn't make it obvious that a package will be created (which is probably the most common reason to want to run on internal jenkins) * We could have multiple labels that mean the same thing: `build-package`, `internal-build`, `run-internal-jenkins`, etc, but it's redundant and I don't quite like it either. * Any other ideas? [2] I'm noticing now that these two look quite similar and this might end up confusing (the main difference is that the comment from the public jenkins will say **Build success/failure** and **Build comment file:** at the top. If something goes wrong the failure will also show up differently). Should this be made clearer?
rolfbjarne
added
the
build-package
|
🔥 Jenkins job (on internal Jenkins) failed in stage 'Running XM tests on '10.7'' 🔥 : hudson.AbortException: script returned exit code 2 ✅ Build succeeded |
Build failure
|
Build failure
|
|
🔥 Jenkins job (on internal Jenkins) failed in stage 'Running XM tests on '10.8'' 🔥 : hudson.AbortException: script returned exit code 2 ✅ Build succeeded |
Build failure
|
|
🔥 Jenkins job (on internal Jenkins) failed in stage 'Provisioning' 🔥 : hudson.AbortException: script returned exit code 1 |
|
Build failure !!! Couldn't read commit file !!! |
|
🔥 Jenkins job (on internal Jenkins) failed in stage 'Running XM tests on '10.12'' 🔥 : hudson.AbortException: script returned exit code 2 ✅ Build succeeded |
|
✅ Jenkins job (on internal Jenkins) succeeded ✅ Build succeeded |
Build failure
|
Quoting empty CONFIGURE_FLAGS ends up doing this:
./configure "" --disable-ios-device
and since configure parses arguments until it finds an empty argument, it
would stop parsing at the first argument, effectively not disabling the device
build.
So don't quote CONFIGURE_FLAGS when invoking configure. shellcheck doesn't
quite like this, but the better code is much more complex, and not really
needed, so just add an exception.
|
✅ Jenkins job (on internal Jenkins) succeeded ✅ Build succeeded |
Build success
|
4 participants
Add support for building on internal Jenkins.
Jenkins has been configured to build every branch on xamarin/xamarin-macios that contains a
jenkins/Jenkinsfile, which means it will start working as soon as this PR is merged.Results will be posted as statuses on each commit, which can be viewed using the url
https://github.com/xamarin/xamarin-macios/commits/<branch>:continuous-integration/jenkins/branchstatus links to the jenkins job.Jenkins-prefix will be removed once we officially switch from Wrench to Jenkins).More detailed information will be added as a comment to each commit, which can be seen by clicking on the commit and scrolling to the bottom (url of the format
https://github.com/xamarin/xamarin-macios/commit/<sha1>)Unfortunately GitHub does not display the commit statuses when viewing a single commit, so to view those statuses you'll have to view the list of commits (the
/commits/url). Tip: it's possible to use<sha1>instead of<branch>(and vice versa for that matter) if you're interested in the statuses of a particular commit.Pull requests will also be built (only from contributors with write access), but by default nothing will be done (the job will exit immediately, although a green check mark will still show up). Jenkins will not add a comment in the pull request in this case.
However, if the label
build-package[1] is set for a pull request, the internal jenkins job will run (it will do everything except the local xharness test run: this includes creating and publishing packages, creating various diffs, run tests on older macOS versions, test docs, etc). A detailed comment will also be added to the pull request (see below for multiple examples), which means that there will be two Jenkins comments: one for the public Jenkins which builds every PR, and one for the internal Jenkins [2].[1] I don't quite like the name of the label, because it doesn't get even close to explain all that will actually happen, but
run-on-internal-jenkins-and-create-packageis a bit too long IMHO... Also it's non-obvious that this is the label to apply if the reason for executing on the internal jenkins is some other reason (for instance to test a maccore bump). Other ideas:run-internal-jenkins: doesn't make it obvious that a package will be created (which is probably the most common reason to want to run on internal jenkins)build-package,internal-build,run-internal-jenkins, etc, but it's redundant and I don't quite like it either.[2] I'm noticing now that these two look quite similar and this might end up confusing (the main difference is that the comment from the public jenkins will say Build success/failure and Build comment file: at the top. If something goes wrong the failure will also show up differently). Should this be made clearer?