OS version not update in mbed_stats

[deepikabhavnani]

Description

Temporary fix to remove OS version update, it will be always zero (even in release versions)

Pull request type

[X] Fix
[ ] Refactor
[ ] New target
[ ] Feature
[ ] Breaking change

CC @0xc0170

[0xc0170]

LGTM

Where should this be documented? Should version member contain a note that this is now 0 as known issue ?

Should this be added to known issue? I assume we will fix this in 5.9.1

[0xc0170]

How does this affect an example system stats? do we nee dto do any change there?

cc @MarceloSalazar

[deepikabhavnani]

How does this affect an example system stats? do we nee dto do any change there?

Example will show version as 0 always. It will be good to document it as known issue. @AnotherButler Shall I add know issue in API reference (handbook) or it should be part of known issues section in Release notes

[cmonr]

/morph build

[mbed-ci]

Build : SUCCESS

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

Triggering tests

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

[mbed-ci]

Test : FAILURE

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

[mbed-ci]

Exporter Build : SUCCESS

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

[adbridge]

mbed OS versions are only applicable in releases. There will never be an OS version on master....This was removed about a year ago.

[adbridge]

@studavekar Looks like we are out of disk space again. Can you take a look please ?

[studavekar]

@studavekar Looks like we are out of disk space again. Can you take a look please ?

@adbridge where did you find traceback of out of disk space? Looking at logs I see ping timeout may be lost connection with node

00:52:27.798 hudson.remoting.ProxyException: java.util.concurrent.TimeoutException: Ping started at 1527733281669 hasn't completed by 1527733989107
00:52:27.798 Caused: Command close created at
00:52:27.798 	at hudson.remoting.Command.<init>(Command.java:60)
00:52:27.798 	at hudson.remoting.Channel$CloseCommand.<init>(C

[studavekar]

/morph test

[cmonr]

Correct, looks like nodes decided to go on a silent strike.
@studavekar just restarted the tests.

[mbed-ci]

Test : SUCCESS

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

[cmonr]

@AnotherButler Ping?

This is ready to go, but I don't want to lose the doc update.

[AnotherButler]

Let's add this to the known issues list in the release notes.

[cmonr]

Fyi @adbridge

[adbridge]

@deepikabhavnani @0xc0170 @cmonr

OK so I am not sure I understand the necessity for this patch? On ALL release branches mbed.h contains:

#define MBED_VERSION MBED_ENCODE_VERSION(MBED_MAJOR_VERSION, MBED_MINOR_VERSION, MBED_PATCH_VERSION) 

stats->os_version is initialised to 0 anyway so this would work fine as it is ? It would report 0 on master where MBED_VERSION is not defined and a real release on a release branch where it is?

[deepikabhavnani]

@adbridge - This is failing because we do not include "mbed.h" inside platform or internal header files. And version number is not available in Mbed OS source code. Correct solution will be to create a separate header file for version details and include that in "mbed.h" and anywhere else as needed.