xamarin-macios/jenkins/productsign.sh

60 строки
1.7 KiB
Bash
Исходник Обычный вид История

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
#!/bin/bash -ex
#
# productsign.sh: run productsign against any installer .pkg
# files in the package output directory for the lane, signing
# with the Xamarin Developer Installer identity and verifying
# the signature's fingerprint after the fact.
#
# Author:
# Aaron Bockover <abock@xamarin.com>
#
# Copyright 2014 Xamarin, Inc.
#
PRODUCTSIGN_KEYCHAIN="login.keychain"
PRODUCTSIGN_IDENTITY="Developer ID Installer: Xamarin Inc"
PRODUCTSIGN_FINGERPRINT="3F:BE:54:B1:41:8B:F1:20:FA:B4:9D:A7:F2:5E:72:95:5A:49:21:D6"
if [ -z "$PRODUCTSIGN_KEYCHAIN_PASSWORD" ]; then
echo "PRODUCTSIGN_KEYCHAIN_PASSWORD is not set."
exit 1
fi
SIGNING_DIR=$(pwd)/package-signed
mkdir -p "$SIGNING_DIR"
echo Before signing
ls -l package
security -v find-identity $PRODUCTSIGN_KEYCHAIN
security unlock-keychain -p "$PRODUCTSIGN_KEYCHAIN_PASSWORD" "$PRODUCTSIGN_KEYCHAIN"
for pkg in package/*.pkg; do
productsign -s "$PRODUCTSIGN_IDENTITY" "$pkg" "$SIGNING_DIR/$(basename "$pkg")" --keychain $PRODUCTSIGN_KEYCHAIN
done
echo Signing output
ls -l "$SIGNING_DIR"
mv "$SIGNING_DIR"/* package
echo After signing
ls -l package
echo 'setns x=http://www.w3.org/2000/09/xmldsig#' > shell.xmllint
echo 'cat (//xar/toc/signature/x:KeyInfo/x:X509Data/x:X509Certificate)[1]/text()' >> shell.xmllint
echo Signature Verification
for pkg in package/*.pkg; do
/usr/sbin/spctl -vvv --assess --type install "$pkg"
pkgutil --check-signature "$pkg"
xar -f "$pkg" --dump-toc="$pkg.toc"
(
echo '-----BEGIN CERTIFICATE-----' &&
xmllint --shell "$pkg.toc" < shell.xmllint | grep -Ev '^/' &&
echo '-----END CERTIFICATE-----'
) | openssl x509 -fingerprint | grep "$PRODUCTSIGN_FINGERPRINT" || exit 1
done
rm shell.xmllint