2016-09-21 17:46:00 +03:00
#!/bin/bash -e
2018-04-05 08:37:08 +03:00
2019-04-27 00:06:12 +03:00
# Script that builds xamarin-macios for CI
#
# --configure-flags=<flags>: Flags to pass to --configure. Optional
# --timeout=<timeout>: Time out the build after <timeout> seconds.
2018-05-29 18:03:54 +03:00
cd " $( dirname " ${ BASH_SOURCE [0] } " ) /.. "
WORKSPACE = $( pwd )
2019-05-29 15:57:49 +03:00
export FAILURE_REASON_PATH = " $WORKSPACE /jenkins/build-failure.md "
2018-04-05 08:37:08 +03:00
report_error ( )
{
2018-05-29 18:03:54 +03:00
printf "🔥 [Build failed](%s/console) 🔥\\n" " $BUILD_URL " >> " $WORKSPACE /jenkins/pr-comments.md "
2019-05-29 15:57:49 +03:00
if test -f " $FAILURE_REASON_PATH " ; then
sed 's/^/* /' " $FAILURE_REASON_PATH " >> " $WORKSPACE /jenkins/pr-comments.md "
fi
2018-04-05 08:37:08 +03:00
}
trap report_error ERR
2019-04-27 00:06:12 +03:00
timeout ( )
{
# create a subprocess that kills this process after a certain number of seconds
SELF_PID = $$
(
sleep " $1 "
echo " Execution timed out after $1 seconds. "
printf "❌ [Build timed out](%s/console)\\n" " $BUILD_URL " >> " $WORKSPACE /jenkins/pr-comments.md "
kill -9 $SELF_PID
) &
# kill the subprocess timeout if we exit before we time out
TIMEOUT_PID = $!
trap 'kill -9 $TIMEOUT_PID' EXIT
}
while ! test -z " $1 " ; do
case " $1 " in
--configure-flags= *)
CONFIGURE_FLAGS = " ${ 1 #*= } "
shift
; ;
--configure-flags)
CONFIGURE_FLAGS = " $2 "
shift 2
; ;
--timeout= *)
TIMEOUT = " ${ 1 #*= } "
shift
; ;
--timeout)
TIMEOUT = " $2 "
shift 2
; ;
*)
echo " Unknown argument: $1 "
exit 1
; ;
esac
done
if test -n " $TIMEOUT " ; then
timeout " $TIMEOUT "
Add support for building on Jenkins. (#4159)
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>`:
![screenshot 2018-06-01 11 12 57](https://user-images.githubusercontent.com/249268/40832932-c3b05eb0-658c-11e8-9670-8de5fcc23407.png)
* 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>`)
![screenshot 2018-06-01 11 14 33](https://user-images.githubusercontent.com/249268/40833014-fd8772f4-658c-11e8-8a35-5df46bfb16c7.png)
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?
2018-06-05 02:40:16 +03:00
fi
2018-05-29 18:03:54 +03:00
ls -la " $WORKSPACE /jenkins "
2018-04-05 08:37:08 +03:00
echo " $WORKSPACE /jenkins/pr-comments.md: "
2018-06-26 16:50:54 +03:00
cat " $WORKSPACE /jenkins/pr-comments.md " || true
2018-04-05 08:37:08 +03:00
2016-09-21 17:46:00 +03:00
export BUILD_REVISION = jenkins
2016-11-17 12:22:26 +03:00
ENABLE_DEVICE_BUILD =
2018-05-29 18:03:54 +03:00
# SC2154: ghprbPullId is referenced but not assigned.
# shellcheck disable=SC2154
if test -z " $ghprbPullId " ; then
Add support for building on Jenkins. (#4159)
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>`:
![screenshot 2018-06-01 11 12 57](https://user-images.githubusercontent.com/249268/40832932-c3b05eb0-658c-11e8-9670-8de5fcc23407.png)
* 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>`)
![screenshot 2018-06-01 11 14 33](https://user-images.githubusercontent.com/249268/40833014-fd8772f4-658c-11e8-8a35-5df46bfb16c7.png)
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?
2018-06-05 02:40:16 +03:00
echo "Could not find the environment variable ghprbPullId, so forcing a device build."
ENABLE_DEVICE_BUILD = 1
2016-11-17 12:22:26 +03:00
else
2018-06-26 16:50:54 +03:00
if ./jenkins/fetch-pr-labels.sh --check= skip-public-jenkins; then
echo "Skipping execution because the label 'skip-public-jenkins' was found."
printf "ℹ ️ [Skipped execution](%s/console)\\n" " $BUILD_URL " >> " $WORKSPACE /jenkins/pr-comments.md "
exit 0
fi
2016-12-03 03:52:24 +03:00
echo " Listing modified files for pull request # $ghprbPullId ... "
if git diff-tree --no-commit-id --name-only -r " origin/pr/ $ghprbPullId /merge^..origin/pr/ $ghprbPullId /merge " > .tmp-files; then
echo "Modified files found" :
2018-05-29 18:03:54 +03:00
sed 's/^/ /' .tmp-files || true
2019-05-12 19:06:06 +03:00
if grep 'mk/mono.mk' .tmp-files > /dev/null; then
2016-12-03 03:52:24 +03:00
echo "Enabling device build because mono was bumped."
2018-12-19 18:56:12 +03:00
ENABLE_DEVICE_BUILD = 1
2016-11-17 12:22:26 +03:00
else
2019-05-12 19:06:06 +03:00
echo "Not enabling device build; mono wasn't bumped."
2016-11-17 12:22:26 +03:00
fi
fi
2016-12-03 03:52:24 +03:00
rm -f .tmp-files
2018-05-29 18:03:54 +03:00
if test -z " $ENABLE_DEVICE_BUILD " ; then
2018-04-27 10:05:50 +03:00
if ./jenkins/fetch-pr-labels.sh --check= enable-device-build; then
ENABLE_DEVICE_BUILD = 1
echo "Enabling device build because the label 'enable-device-build' was found."
2016-12-03 03:52:24 +03:00
else
2018-04-27 10:05:50 +03:00
echo "Not enabling device build; no label named 'enable-device-build' was found."
2016-12-03 03:52:24 +03:00
fi
fi
2019-04-25 18:18:43 +03:00
if ./jenkins/fetch-pr-labels.sh --check= run-sample-tests; then
echo "The sample tests won't be triggered from public jenkins even if the 'run-sample-tests' label is set (build on internal Jenkins instead)."
2020-11-03 16:13:44 +03:00
printf "ℹ ️ The sample tests won't be triggered from public jenkins even if the 'run-sample-tests' label is set (build on internal Jenkins instead).\\n" >> " $WORKSPACE /jenkins/pr-comments.md "
2019-04-25 18:18:43 +03:00
fi
2019-04-30 08:23:49 +03:00
if ./jenkins/fetch-pr-labels.sh --check= disable-packaged-mono; then
echo "Building mono from source because the label 'disable-packaged-mono' was found."
CONFIGURE_FLAGS = " $CONFIGURE_FLAGS --disable-packaged-mono "
fi
2016-11-17 12:22:26 +03:00
fi
2019-04-25 18:18:43 +03:00
2018-06-07 19:55:31 +03:00
if test -z " $ENABLE_DEVICE_BUILD " ; then
CONFIGURE_FLAGS = " $CONFIGURE_FLAGS --disable-ios-device "
2016-11-17 12:22:26 +03:00
fi
2020-03-06 00:03:38 +03:00
# Enable dotnet bits on the bots
2020-06-22 11:26:21 +03:00
CONFIGURE_FLAGS = " $CONFIGURE_FLAGS --enable-dotnet --enable-install-source "
2020-03-06 00:03:38 +03:00
2018-12-19 18:56:12 +03:00
echo " Configuring the build with: $CONFIGURE_FLAGS "
2018-10-03 09:18:11 +03:00
# shellcheck disable=SC2086
./configure $CONFIGURE_FLAGS
2019-10-04 10:55:29 +03:00
# If we're building mono from source, we might not have it cloned yet
make reset
Add support for building on Jenkins. (#4159)
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>`:
![screenshot 2018-06-01 11 12 57](https://user-images.githubusercontent.com/249268/40832932-c3b05eb0-658c-11e8-9670-8de5fcc23407.png)
* 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>`)
![screenshot 2018-06-01 11 14 33](https://user-images.githubusercontent.com/249268/40833014-fd8772f4-658c-11e8-8a35-5df46bfb16c7.png)
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?
2018-06-05 02:40:16 +03:00
time make -j8
time make install -j8
2018-04-05 08:37:08 +03:00
2018-05-29 18:03:54 +03:00
printf "✅ [Build succeeded](%s/console)\\n" " $BUILD_URL " >> " $WORKSPACE /jenkins/pr-comments.md "
2019-10-04 10:55:29 +03:00
if grep MONO_BUILD_FROM_SOURCE = . configure.inc Make.config.inc >& /dev/null; then
printf " ⚠️ Mono built from source\\n" >> " $WORKSPACE /jenkins/pr-comments.md "
fi