This means we'll get an empty diff if there are no generator changes, so
update the logic that detects/reports empty generator diffs.
Also there's no need to ignore mdbs anymore, since we don't create mdbs.
This can be useful when working on the support for private jenkins, since many
of those changes can only be tested as a pull request, and they also tend to
include a lot of commits (because nothing can be tested locally).
So until whatever needs implementing for private jenkins is complete and
working, there's no need for the public bots to do anything for such pull
requests.
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?
For the api diff for this PR we now show:
* `🔥 breaking changes 🔥`: If there are any breaking changes in the api diff (for this PR).
* `please review changes`: If there are any non-breaking changes in the api diff.
* `no change`: If the api diff is empty.
For the generator diff we show:
* `only version changes`: If there were only changes related to version numbers (since the XI/XM version number is added to the generator, that version number will always show up as a diff when comparing the generated source code)
* `please review changes`: If anything other that version numbers changed in the generated source code.
A few general categories of fixes:
* Sprinkle lots of quotes everywhere.
* Don't use environment variables in the format string to printf, instead pass them as arguments.
* Don't use backticks to execute commands (it's deprecated), use the new "$(...)" syntax instead.
Implement support for skipping API comparison by applying a label to a pull
request.
This also required some refactoring to move existing code to fetch the labels
for a pull request to a separate script.
We can't create an API/generator diff for a pull request with conflicts, so
detect this scenario and show a better error than this (from #3961):
Comparing the changes between origin/pr/3961/merge^1 and HEAD:
fatal: ambiguous argument 'origin/pr/3961/merge^1..HEAD': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions, like this:
'git <command> [<revision>...] -- [<file>...]'
fatal: ambiguous argument 'origin/pr/3961/merge^1': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions, like this:
'git <command> [<revision>...] -- [<file>...]'
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?
For the api diff for this PR we now show:
* `🔥 breaking changes 🔥`: If there are any breaking changes in the api diff (for this PR).
* `please review changes`: If there are any non-breaking changes in the api diff.
* `no change`: If the api diff is empty.
For the generator diff we show:
* `only version changes`: If there were only changes related to version numbers (since the XI/XM version number is added to the generator, that version number will always show up as a diff when comparing the generated source code)
* `please review changes`: If anything other that version numbers changed in the generated source code.
A few general categories of fixes:
* Sprinkle lots of quotes everywhere.
* Don't use environment variables in the format string to printf, instead pass them as arguments.
* Don't use backticks to execute commands (it's deprecated), use the new "$(...)" syntax instead.
Implement support for skipping API comparison by applying a label to a pull
request.
This also required some refactoring to move existing code to fetch the labels
for a pull request to a separate script.
We can't create an API/generator diff for a pull request with conflicts, so
detect this scenario and show a better error than this (from #3961):
Comparing the changes between origin/pr/3961/merge^1 and HEAD:
fatal: ambiguous argument 'origin/pr/3961/merge^1..HEAD': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions, like this:
'git <command> [<revision>...] -- [<file>...]'
fatal: ambiguous argument 'origin/pr/3961/merge^1': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions, like this:
'git <command> [<revision>...] -- [<file>...]'
* [jenkins] Create comment file for PR builds. (#3799)
* [jenkins] Create comment file for PR builds.
* [tools] Create stamp file after doing things that might modify files we care about. (#3864)
We have consistency checks to verify that no unexpected files are modified
done when comparing APIs in for a pull request.
Unfortunately the check didn't take into account that checking out the
revision to do the API check against might modify some of the files in the
consistency check itself, thus triggering the consistency check.
Fix this by only verify timestamps of files modified after checkout out the
revision, which is the only thing we care about anyway.
For examples see PR #3855 or PR #3850.
* [jenkins] Don't succeed if something went wrong when creating API or generator diff. (#3865)
Ref: https://github.com/xamarin/xamarin-macios/pull/3855#issuecomment-378441993
Rolf Bjarne Kvinge
Vincent Dondain
