search

ARMmbed / mbed-os-example-blinky

Blinky example for Mbed OS 6.0
Apache License 2.0
42 stars 157 forks source link

Update `mbed-os.lib` to Mbed OS latest #248

Closed jainvikas8 closed 3 years ago

jainvikas8 commented 3 years ago

Always point to the latest version of Mbed-OS for testing purpose

0xc0170 commented 3 years ago

@adbridge this should be OK with the current flow (development tracking Mbed OS), although there was a point about reproducibility. This should however not apply with development as it should caught issues with master early?

0xc0170 commented 3 years ago

@rajkan01 is updating all examples to add travis build for CMake (this nicely align) 💯

adbridge commented 3 years ago

This won't work as the mbed-os.lib is overwritten on the development branch when we make a new release. See here for how the examples are currently maintained and released: https://confluence.arm.com/display/BSGSoftware/IOT-OS-M+Mbed+OS+Example+Maintenance

adbridge commented 3 years ago

What you actually want to achieve is to always test the example on the development branch against the latest version of mbed-os. This can be done in the CI and I believe is how it is supposed to work anyway @jamesbeyond can confirm...and if not it could be adjusted to do so.

0xc0170 commented 3 years ago

This won't work as the mbed-os.lib is overwritten on the development branch when we make a new release.

it's just implementation detail, we can fix the update flow for releasing.

What you actually want to achieve is to always test the example on the development branch against the latest version of mbed-os.

This is important detail we should focus on. What is development branch in the examples. We should talk with the rest of the team to agree on this and update our example workflow accordingly. I recall we wanted previously non sha in .lib, before we had development branch. So lets revise this together.

Note, we are about to release the next version so this should not be merged at least until we release the next Mbed OS.

adbridge commented 3 years ago

Development branch is precisely as the name states - it is for on-going development and it is where we take snapshots from to make the next release (along with mbed-os releases). If we want to make the change detailed on this PR then we would need to update our release script to adjust how we update and release the examples. One way we could do this would be for each new release to branch from 'development' to a staging branch e.g something like 'release-candidate'. We could update the version of mbed-os.lib on the staging branch before raising the PR from there to the release (ie master) branch.

jamesbeyond commented 3 years ago

What you actually want to achieve is to always test the example on the development branch against the latest version of mbed-os. This can be done in the CI and I believe is how it is supposed to work anyway @jamesbeyond can confirm...and if not it could be adjusted to do so.

I can confirm that, in mbed OS CI Jenkins test, we ignore all mbed-os.lib file in all circumstances. the reason for that is we are not testing the mbed-os that sha pointed to, we are testing a future mbed-OS which contains the PR to be merged.

So change mbed-os.lib in any example will not impact us

Testing the sha pointed mbed-os, is on example's own CircleCI test

Patater commented 3 years ago

Here's the user experience if we don't update the development branch to point to an mbed-os that it is supposed to work with:

$ mbed import https://github.com/ARMmbed/mbed-os-example-blinky
$ cd mbed-os-example-blinky
$ git checkout origin/development
$ mbed deploy
$ mbed build -t GCC_ARM -m K64F
ERROR because mbed-os.lib points to 6.4.0 release instead of master
$ cd mbed-os
$ git checkout origin/master
$ cd ..
$ mbed build -t GCC_ARM -m K64F
OK

If we ensure that the mbed-os.lib file always points to a working mbed-os.lib for a branch, we get this experience.

$ mbed import https://github.com/ARMmbed/mbed-os-example-blinky
$ cd mbed-os-example-blinky
$ git checkout origin/development
$ mbed deploy
$ mbed build -t GCC_ARM -m K64F
OK
adbridge commented 3 years ago

@Patater as I said above we can change this but it requires updates to our release script

Patater commented 3 years ago

I've raised PRs to update mbed-os.lib for all examples and cloud examples. (One such example is https://github.com/ARMmbed/mbed-os-example-blinky-baremetal/pull/47)

After that, the release script will need updating to avoid changing mbed-os.lib on development, only changing it for the main/default branch for tagged releases via release branches as commented previously.