Add support for building on Jenkins. by rolfbjarne · Pull Request #4159 · dotnet/macios

rolfbjarne · 2018-05-30T10:25:16Z

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?

monojenkins · 2018-05-31T10:02:04Z

Build failure
Build comment file:

✅ Build succeeded
✅ API Diff (from stable)
✅ API Diff (from PR only) (no change)
✅ Generator Diff (only version changes)

rolfbjarne · 2018-05-31T10:27:32Z

🔥 Jenkins job failed in stage 'Running XM tests on '10.10'' 🔥 : hudson.AbortException: script returned exit code 2

✅ Build succeeded
✅ API Diff (from stable)
✅ API Diff (from PR only) (no change)
✅ Generator Diff (only version changes)

monojenkins · 2018-05-31T12:24:51Z

Build success
Build comment file:

✅ Build succeeded
✅ API Diff (from stable)
✅ API Diff (from PR only) (no change)
✅ Generator Diff (only version changes)
✅ Test run succeeded

rolfbjarne · 2018-05-31T13:22:36Z

🔥 Jenkins job failed in stage 'Running XM tests on '10.10'' 🔥 : hudson.AbortException: script returned exit code 2

✅ Build succeeded
✅ API Diff (from stable)
✅ API Diff (from PR only) (no change)
✅ Generator Diff (only version changes)

monojenkins · 2018-05-31T14:31:08Z

Build success
Build comment file:

✅ Build succeeded
✅ API Diff (from stable)
✅ API Diff (from PR only) (no change)
✅ Generator Diff (only version changes)
✅ Test run succeeded

rolfbjarne · 2018-05-31T14:58:01Z

🔥 Jenkins job failed in stage 'Running XM tests on '10.10'' 🔥 : hudson.AbortException: script returned exit code 2

✅ Build succeeded
✅ API Diff (from stable)
✅ API Diff (from PR only) (🔥 breaking changes 🔥)
✅ Generator Diff (please review changes)

monojenkins · 2018-06-01T06:56:15Z

Build success
Build comment file:

✅ Build succeeded
✅ API Diff (from stable)
✅ API Diff (from PR only) (no change)
✅ Generator Diff (only version changes)
✅ Test run succeeded

rolfbjarne · 2018-06-01T06:58:50Z

🔥 Jenkins job failed in stage 'Running XM tests on '10.9'' 🔥 : hudson.AbortException: script returned exit code 2

✅ Build succeeded
✅ API Diff (from stable)
✅ API Diff (from PR only) (no change)
✅ Generator Diff (only version changes)

rolfbjarne · 2018-06-01T09:35:36Z

The test failures private Jenkins are known (tests fail on older macOS bots due to #4129).

rolfbjarne · 2018-06-01T09:37:43Z

@xamarin/macios This is ready for review now. Please also take a look at the job at private jenkins to see if there are any questions/improvements that can be done (The Jenkins job link in the last comment: http://xamarin-jenkins.guest.corp.microsoft.com:8080/job/macios/job/PR-4159/18/display/redirect)

mandel-macaque · 2018-06-01T11:36:52Z

+createFinalStatus = true
+skipLocalTestRunReason = ""
+
+def abortExecutingBuilds ()


Since this is all commented, do we need it in the diff? Or should it be deleted?

It will be working pretty soon (needs some changes to Jenkins itself first), but I can remove it.

mandel-macaque · 2018-06-01T11:37:39Z

+            try {
+                sh ("curl -vf -H 'Authorization: token ${GITHUB_PAT_TOKEN}' --output '${outputFile}' '${url}'")
+                github_pull_request_info = readJSON (file: outputFile)
+                echo ("Got pull request info: ${github_pull_request_info}")


Do we want to log the exception for easier debugging?

The exception is not caught, it will bubble up and eventually fail the job.

mandel-macaque · 2018-06-01T11:38:42Z

+            def labels = pinfo ["labels"]
+            if (labels != null) {
+                for (int i = 0; i < labels.size (); i++) {
+                    def label = labels [i]


Why not labels[i]["name"]? Also, I suppose that we are 100% sure that label does have the "name" key, right?

This is how it ended up after I removed all the debug spew that was between these two statements 😄

And yes, every label has a name, this comes from GitHub's API, which is considered stable on their end.

mandel-macaque · 2018-06-01T11:39:07Z

+        withCredentials ([string (credentialsId: 'macios_github_comment_token', variable: 'GITHUB_COMMENT_TOKEN')]) {
+            sh ("curl -i -H 'Authorization: token ${GITHUB_COMMENT_TOKEN}' ${url} --data '@${jsonFile}'")
+        }
+    } finally {


Same as previous, do we want to log exceptions?

Same answer 😄

Fair enough ;)

mandel-macaque · 2018-06-01T11:41:24Z

+            def pinfo = githubGetPullRequestInfo ()
+            def labels = pinfo ["labels"]
+            if (labels != null) {
+                for (int i = 0; i < labels.size (); i++) {


AFAIK groovy has foreach loops, like label.each { // your code }, should we use them?

Yeah, we could. OTOH doesn't matter in any way, and the current code works (and is more familiar to us C# developers), so I prefer the current version.

mandel-macaque · 2018-06-01T11:41:44Z

+    try {
+        sh (script: "grep '^@MonkeyWrench: ...Summary: ' '${outputFile}' > ${tmpfile}", returnStatus: true /* don't throw exceptions if something goes wrong */)
+        def lines = readFile ("${tmpfile}").split ("\n")
+        for (int i = 0; i < lines.length; i++) {


Same, we could use each here.

Same answer 😄

mandel-macaque · 2018-06-01T11:42:18Z

+                            def uploadingFiles = findFiles (glob: "package/*")
+                            def manifest = ""
+                            def metadata = "[\n"
+                            for (int i = 0; i < uploadingFiles.length; i++) {


Same, should we use each?

Same answer 😄

dalexsoto

[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?

What about internal-build-and-package? Most of the time we are the ones applying the labels and we could document them in the maccore wiki including the need of applying it when bumping maccore. I am not really keen to the idea of having multiple labels meaning the same thing.

Tooling wise it looks good to me 👍

spouliot

Q: How can we identify PR-based packages ?

Should we overload a variable (maybe PACKAGE_REV) to a known value so we don't get duplicates ? (or at least no duplicate with normal builds)

I guess the branch name will also point the the PR name (but we don't really control the names)

chamons

❤️

monojenkins · 2018-06-01T14:10:22Z

Build success
Build comment file:

✅ Build succeeded
✅ API Diff (from stable)
✅ API Diff (from PR only) (no change)
✅ Generator Diff (only version changes)
✅ Test run succeeded

rolfbjarne · 2018-06-01T14:59:00Z

🔥 Jenkins job failed in stage 'Running XM tests on '10.8'' 🔥 : hudson.AbortException: script returned exit code 2

✅ Build succeeded
✅ API Diff (from stable)
✅ API Diff (from PR only) (no change)
✅ Generator Diff (only version changes)

VincentDondain

I like the label build-package it's indeed likely what we care about, the fact it's internal jenkins doesn't matter much IMHO and I see the fact that we're running a larger subset of the tests as a requirement to build a package (:

I do think we should update the status messages, right now they are too similar. The titles should clearly explain what is what. In addition, it might be a good idea to have a 1 liner description of the differences between what internal and external Jenkins do.

Also why do we have 🔥 Jenkins job failed in stage 'Running XM tests on '10.8'' 🔥 : hudson.AbortException: script returned exit code 2 at the top and not a 🔥 Test run failed step.

spouliot · 2018-06-01T15:32:17Z

I think it's because it's running on older macOS bots
However when I click on the link I get to Run tests parallelized / XM tests on 10.10 - <1s
i.e. not 10.8

rolfbjarne · 2018-06-01T15:44:42Z

@spouliot

Q: How can we identify PR-based packages ?

Should we overload a variable (maybe PACKAGE_REV) to a known value so we don't get duplicates ? (or at least no duplicate with normal builds)

I guess the branch name will also point the the PR name (but we don't really control the names)

Right now nothing will show that it was built from a PR (except the download link itself, and indirectly from the hash in mtouch --version. The branch shown will be the value of PACKAGE_HEAD_BRANCH).

I don't quite like messing with the version numbers themselves, since that ends up being "hardcoded knowledge", and it also makes version comparisons non-intuitive.

However, I can make the actual branch name (and something like pr#### for pull requests [1]) show up in mtouch --version now, since jenkins knows the branch name (which makes it possible to remove the PACKAGE_HEAD_BRANCH clutch we have).

Does that sound like a plan?

[1] I can even make it say something very explicit, like the full url of the PR:

$ mtouch --version
mtouch 11.11.0.374 (https://github.com/xamarin/xamarin-macios/pull/4159: 3db25d1c)

monojenkins · 2018-06-01T17:24:50Z

Build success
Build comment file:

✅ Build succeeded
✅ API Diff (from stable)
✅ API Diff (from PR only) (no change)
✅ Generator Diff (only version changes)
✅ Test run succeeded

rolfbjarne · 2018-06-01T17:31:03Z

🔥 Jenkins job (on internal Jenkins) failed in stage 'Running XM tests on '10.8'' 🔥 : java.io.IOException: java.nio.file.NoSuchFileException: /Users/builder/jenkins/workspace/xamarin-macios/xamarin-macios/ℹ️ Test run skipped: Not running tests here because they're run on public Jenkins.

✅ Build succeeded
✅ API Diff (from stable)
✅ API Diff (from PR only) (no change)
✅ Generator Diff (only version changes)

monojenkins · 2018-06-01T18:46:25Z

Build success
Build comment file:

✅ Build succeeded
✅ API Diff (from stable)
✅ API Diff (from PR only) (no change)
✅ Generator Diff (only version changes)
✅ Test run succeeded

rolfbjarne · 2018-06-01T19:04:12Z

🔥 Jenkins job (on internal Jenkins) failed in stage 'Running XM tests on '10.8'' 🔥 : hudson.AbortException: script returned exit code 2

✅ Build succeeded
✅ API Diff (from stable)
✅ API Diff (from PR only) (no change)
✅ Generator Diff (only version changes)
ℹ️ Test run skipped: Not running tests here because they're run on public Jenkins.🔥 Xamarin.Mac tests on 10.10 failed 🔥
🔥 Xamarin.Mac tests on 10.7 failed 🔥
🔥 Xamarin.Mac tests on 10.9 failed 🔥
🔥 Xamarin.Mac tests on 10.8 failed 🔥

rolfbjarne · 2018-06-01T22:09:18Z

@spouliot: this is how the version shows up now:

$ mtouch --version
mtouch 11.11.0.379 (PR-4159: 5b6240b9)

monojenkins · 2018-06-01T22:18:14Z

Build success
Build comment file:

✅ Build succeeded
✅ API Diff (from stable)
✅ API Diff (from PR only) (no change)
✅ Generator Diff (only version changes)
✅ Test run succeeded

rolfbjarne · 2018-06-01T23:03:41Z

🔥 Jenkins job (on internal Jenkins) failed in stage 'Running XM tests on '10.7'' 🔥 : hudson.AbortException: script returned exit code 2

✅ Build succeeded
✅ API Diff (from stable)
✅ API Diff (from PR only) (no change)
✅ Generator Diff (only version changes)
ℹ️ Test run skipped: Not running tests here because they're run on public Jenkins.
🔥 Xamarin.Mac tests on 10.9 failed 🔥
🔥 Xamarin.Mac tests on 10.10 failed 🔥
🔥 Xamarin.Mac tests on 10.8 failed 🔥
🔥 Xamarin.Mac tests on 10.7 failed 🔥

rolfbjarne · 2018-06-01T23:10:15Z

build

monojenkins · 2018-06-02T01:24:00Z

Build success
Build comment file:

✅ Build succeeded
✅ API Diff (from stable)
✅ API Diff (from PR only) (no change)
✅ Generator Diff (only version changes)
✅ Test run succeeded

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?

* 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? * Make the Jenkins packages official. * [Jenkins] Create artifacts.json and set a GH status as 'Jenkins: Artifacts'. * [jenkins] Include the url in artifacts.json * [jenkins] Add sha256 checksum to artifacts.json as well. * [Jenkins] Enable xamarin before provisioning so that we auto-provision Xcode. * [jenkins] Fix passing flags to configure. 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.

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?

rolfbjarne added skip-all-tests Skip all the tests do-not-merge Do not merge this pull request build-package Build (and create package) on internal Jenkins. Apply 'run-internal-tests' to run tests too. labels May 30, 2018

rolfbjarne force-pushed the jenkinsfile branch from 0c2948b to f776df8 Compare May 31, 2018 08:29

dotnet deleted a comment from monojenkins May 31, 2018

Add support for building on Jenkins.

db34a5b

rolfbjarne force-pushed the jenkinsfile branch from e29f1e9 to db34a5b Compare June 1, 2018 05:41

rolfbjarne changed the title ~~[WIP] Add support for building on Jenkins.~~ Add support for building on Jenkins. Jun 1, 2018

mandel-macaque reviewed Jun 1, 2018

View reviewed changes

dalexsoto approved these changes Jun 1, 2018

View reviewed changes

Remove unused code.

3db25d1

spouliot approved these changes Jun 1, 2018

View reviewed changes

chamons approved these changes Jun 1, 2018

View reviewed changes

VincentDondain reviewed Jun 1, 2018

View reviewed changes

rolfbjarne added 3 commits June 1, 2018 18:06

[jenkins] Make it a bit clearer on which Jenkins we're running.

7882e07

[jenkins] Improve reporting a bit.

16b064c

Set the branch name correctly for Jenkins-built packages.

f6bfae2

Fix string interpolation.

ebba473

Read the file, not the comment...

5b6240b

spouliot approved these changes Jun 1, 2018

View reviewed changes

Add missing newline.

b735c2f

rolfbjarne removed do-not-merge Do not merge this pull request skip-all-tests Skip all the tests labels Jun 1, 2018

rolfbjarne merged commit dbe1051 into dotnet:master Jun 4, 2018

rolfbjarne mentioned this pull request Jun 12, 2018

Cherry-pick changes from master to implement support for building on internal Jenkins. #4224

Merged

Uh oh!

Conversation

rolfbjarne commented May 30, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

monojenkins commented May 31, 2018

Build failure Build comment file:

Uh oh!

rolfbjarne commented May 31, 2018

Uh oh!

monojenkins commented May 31, 2018

Build success Build comment file:

Uh oh!

rolfbjarne commented May 31, 2018

Uh oh!

monojenkins commented May 31, 2018

Build success Build comment file:

Uh oh!

rolfbjarne commented May 31, 2018

Uh oh!

monojenkins commented Jun 1, 2018

Build success Build comment file:

Uh oh!

rolfbjarne commented Jun 1, 2018

Uh oh!

rolfbjarne commented Jun 1, 2018

Uh oh!

rolfbjarne commented Jun 1, 2018

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

dalexsoto left a comment

Choose a reason for hiding this comment

Uh oh!

spouliot left a comment

Choose a reason for hiding this comment

Uh oh!

chamons left a comment

Choose a reason for hiding this comment

Uh oh!

monojenkins commented Jun 1, 2018

Build success Build comment file:

Uh oh!

rolfbjarne commented Jun 1, 2018

Uh oh!

VincentDondain left a comment

Choose a reason for hiding this comment

Uh oh!

spouliot commented Jun 1, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rolfbjarne commented Jun 1, 2018

rolfbjarne commented May 30, 2018 •

edited

Loading

Build failure
Build comment file:

Build success
Build comment file:

Build success
Build comment file:

Build success
Build comment file:

Build success
Build comment file:

spouliot commented Jun 1, 2018 •

edited

Loading

Build success
Build comment file:

Build success
Build comment file:

rolfbjarne commented Jun 1, 2018 •

edited

Loading

Build success
Build comment file:

Build success
Build comment file: