Remove mbed 2 builds from Travis

[geky]

@studavekar got mbed 2 builds running on the Jenkins CI! Now it is much faster (~3 min as opposed to >30 min). There should now be an mbed-ci-mbed2-build job on all PRs.

I've removed the mbed 2 builds from Travis now. @0xc0170, if you can can you double check that the mbed-ci-mbed2-build output is correct?

cc @0xc0170, @theotherjimmy, @studavekar

[geky]

/morph mbed2-build

[0xc0170]

@studavekar got mbed 2 builds running on the Jenkins CI! Now it is much faster (~3 min as opposed to >30 min). There should now be an mbed-ci-mbed2-build job on all PRs.

💯

Can we get mbed2 build report back results (public access) ? will mbed build trigger also this job? will test

/morph build

[mbed-ci]

Build : SUCCESS

Build number : 1155
Build artifacts/logs : http://mbed-os.s3-website-eu-west-1.amazonaws.com/?prefix=builds/6114/

Triggering tests

/morph test
/morph uvisor-test
/morph export-build
/morph mbed2-build

[mbed-ci]

Test : SUCCESS

Build number : 960
Test logs :http://mbed-os-logs.s3-website-us-west-1.amazonaws.com/?prefix=logs/6114/960

[mbed-ci]

Exporter Build : FAILURE

Build number : 829
Build artifacts/logs : http://mbed-os.s3-website-eu-west-1.amazonaws.com/?prefix=builds/exporter/6114/

[0xc0170]

/morph export-build

[mbed-ci]

Exporter Build : FAILURE

Build number : 834
Build artifacts/logs : http://mbed-os.s3-website-eu-west-1.amazonaws.com/?prefix=builds/exporter/6114/

[0xc0170]

/morph export-build

[0xc0170]

I review the test results.
What we are missing there is to link some examples, as build_travis.py does (see there linking_list). It's limited there but does it for quite some number of platforms. We have a similar step for our regular CI (examples build).

If this goes in, Test logs should be available same as regular morph CI does

@studavekar Please review

[mbed-ci]

Exporter Build : SUCCESS

Build number : 848
Build artifacts/logs : http://mbed-os.s3-website-eu-west-1.amazonaws.com/?prefix=builds/exporter/6114/

[studavekar]

@0xc0170 yes will have a link pointed to public results, have to take a look at example we are not building.

[studavekar]

test the public log link in status
/morph mbed2-build

[studavekar]

We have a public link to results in status http://mbed-os.s3-website-eu-west-1.amazonaws.com/?prefix=builds/mbed2-release/6114/

[geky]

@studavekar, are we going to put links in all the morph statuses?

[studavekar]

@studavekar, are we going to put links in all the morph statuses?

currently, we point to internal matirx bit pretty to look at :). It would be a trivial change to point to log location. If its useful to have the public there instead can do it.

[studavekar]

@0xc0170 I was looking at the scripts does it make sense to use build_travis.py directly? we would have identical results as current Travis job.

[0xc0170]

We have a public link to results in status http://mbed-os.s3-website-eu-west-1.amazonaws.com/?prefix=builds/mbed2-release/6114/

This is nice (the job provides hook with results), if as @geky mentioned we can do for others as well, then we do not need to post a comment each time.
One note: if job fails multiple times (how to track the log then to compare if failures persist for instance, travis have this for instance) - might be just nice to have?
@cmonr @adbridge @theotherjimmy @kjbracey-arm What do you think?

If job fails and the link is to the public log, we will need to document (or provide internal link reference there somewhere) how to get to the CI log for review in case of failures (in situations like public logs are not published because of earlier CI stage failures or similar).

@0xc0170 I was looking at the scripts does it make sense to use build_travis.py directly? we would have identical results as current Travis job.

run_test_linking function? that would be fine for this PR. We will review this stage and will improve it separately.

[cmonr]

@0xc0170 I strongly think that we need a way to track a job that fails multiple times. I've lost count as to how many times I've wanted to look back at an older issue for the exact failure details, only to be greeted by an error page saying the logs were no longer available.

Though for the short term, I'm fine with leaving it as a nice-to-have for sometime in the (hopefully) near future.

[cmonr]

@geky @studavekar Looking at this PR again, it looks like the Jenkins functionality is already in and the feedback question was us bikeshedding over the PR.

Aside for the rebase that is now needed, is there anything else that needs to be done either in Jenkins or elsewhere before we migrate the mbed2 builds from TravisCI to Jenkins?

[studavekar]

@cmonr, #6114 (comment) I assume we are ok to run build_travis.py?

an update should be statues/comment can we be taken offline?

[0xc0170]

@cmonr, #6114 (comment) I assume we are ok to run build_travis.py?

Yes

Lets make this ready! (needs a rebase now).

[geky]

Sorry about the delay, should be good to go

[cmonr]

/morph build

[mbed-ci]

Build : FAILURE

Build number : 1442
Build artifacts/logs : http://mbed-os.s3-website-eu-west-1.amazonaws.com/?prefix=builds/6114/

[0xc0170]

/morph build

[mbed-ci]

Build : SUCCESS

Build number : 1457
Build artifacts/logs : http://mbed-os.s3-website-eu-west-1.amazonaws.com/?prefix=builds/6114/

Triggering tests

/morph test
/morph uvisor-test
/morph export-build
/morph mbed2-build

[cmonr]

Test was stopped to prioritize 5.7.7 mbed2 compilation.
/morph test

[mbed-ci]

Exporter Build : SUCCESS

Build number : 1097
Build artifacts/logs : http://mbed-os.s3-website-eu-west-1.amazonaws.com/?prefix=builds/exporter/6114/

[mbed-ci]

Test : FAILURE

Build number : 1227
Test logs :http://mbed-os-logs.s3-website-us-west-1.amazonaws.com/?prefix=logs/6114/1227

[cmonr]

CI issue: NRF52 flash cache test

Restarting.
/morph test

[mbed-ci]

Test : FAILURE

Build number : 1234
Test logs :http://mbed-os-logs.s3-website-us-west-1.amazonaws.com/?prefix=logs/6114/1234

[studavekar]

CI issue: NRF52 flash cache test

Restarting.
/morph test

@cmonr should it be more of NRF52 issue failing the test? We should either fix the test or take it out.

Re-triggering CI till it passes is not a solution.

[mbed-ci]

Test : SUCCESS

Build number : 1236
Test logs :http://mbed-os-logs.s3-website-us-west-1.amazonaws.com/?prefix=logs/6114/1236