This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Integrating a Keil project in a continuous delivery system

Hello,

We are looking at integrating our existing projects in the context of a continuous delivery system. Specifically we need to have a way to automatically compile a Keil project from command line from a server machine when a developer pushes a new commit on a server. Ideally, we want to integrate it on an existing CI software suite such as gitlab/github or travis CI or circle CI.

Is there a way to compile a Keil project from command line?

Is there a way to share a Keil license to a CI framework?

Thanks

  • Licensing --

    If you have complex issues, reach out to your support rep. For basic issues, the rules are as follows: if you have a floating licenses, you would set up your CI build machine to point to your floating license server. During build, one of your licenses will be consumed. If you have user-locked licenses, then Keil permits you to set up a second instance of a user license on a another computer. The basic rule is that a license is for exactly one person. But each person is allowed to have that license on two computers, as long as its the same person using it. Example: a work laptop and a work desktop. I asked this exact question to our Keil/ARM support rep and he explicitly informed me that a build machine qualifies as this. I.e., one person on your team can assign their second-machine capability to your build server. C.f. https://www.keil.com/support/man/docs/license/license_single_user.htm or the main page. https://www.keil.com/support/man/docs/license/license_management.htm.  

    One last note: if your team uses floating licenses, it may sound convenient to just point your builder to that license server. But... you may want to consider buying a user license (non-floating) anyway, so as to eliminate any form of license contention. If your team has all your licenses in use and the build server kicks off a build, it will fail. If your company takes a lot of stock in build metrics, you may be better served to make sure your build system is pristine from an "always gonna have the necessary resources" standpoint.

    Command line --

    This is very straightforward, see https://www.keil.com/support/man/docs/uv4/uv4_commandline.htm. The simplest approach is perhaps just invoking the uv4.exe from powershell, cmdline, etc.

    However, if you want to get fancy, you can also write a wrapper in Python or C# or Java... we found it convenient to use a C# wrapper that calls the uv4.exe from the System.Diagnostics.Process. This allows us to implement some more complex flows depending on the test case. For instance, beyond building, you can also reflash, you can launch the IDE and start a debugging session, and several other flows. It was not hard at all and has been super reliable.

    Note: you may find it useful to pair your CI platform with a specialized initialization (*.ini) file, located: uVision, Project Options > Debug > Initialization File. For instance after you flash an image via the command line, it just sits there, not running. For a proper CI platform test, you probably want it to start!!

    To solve this, as you may be aware, Keil has a shell baked into the IDE where you can quickly script things. https://www.keil.com/support/man/docs/uv4/uv4_debug_commands.htm The initialization file is just a way to automatically invoke one or more of these commands as a matter of convenience. So: our system, among other things, calls

    G // Go (don't stop). Ref: www.keil.com/.../uv4_cm_go.htm

    ...which has the effect or starting the app after it has been programmed.

    Tools --

    Lastly, in terms of reliability, quality and "likeliness to work" the Keil emulators, uLink, etc. are top tier in my opinion. However, we have a whole rack of parallel CI platforms, and the Keil emulators are expensive (> $1000). So we have uLinks for our developers to use, and we have our CI platforms using STLink adaptors ($20). StLinks suck in debugging, but they have worked fine for the simplistic programming workflows.