OpenLMIS build info and build number proposal

[plal]

Hello,

Since I started working on OLMIS-853 I have prepared a proposal of build info and build number format.
Given the fact, that build number should be readable for testers (OLMIS-852) I would recommend following format:
YY.MM.DD/N°, where N° stands for number of builds in particular day (starting from 1)
e.g. 16.08.01/1
This solution gives ability to clearly recognize build number and is more elegant than plain "4536".

Build number, branch and timestamp can be placed in version file (available from repository).
Example content:
Build: 16.08.01/1
Branch: master
Timestamp: 2016-08-01 11:17:10:150 GMT

Version file can be generated during Jenkins build as a build artifact (using task) and saved both locally and to github repository (should it be saved only after successful builds?).
That way, even if the abovementioned task would be accidentally run by a programmer, Jenkins will overwrite version file taking into account it's local version (so the programmer's change won't have any negative effect).

Please let me know what is your opinion about it.

Best regards,
Paweł Lal

[Sebastian Brudziński]

Thanks Pawel. I've got some comments.

I think we should also include some ID of the service in the build number. This could simply be the service name. I also don't quite like the idea of having the counter reset each day (which timezone would be used anyways?). Even if we keep the date, I'd go with unique, incremental build number for each service, which makes it easy to compare with the local build.

I assume we only generate the version file for Jenkins builds, right? I don't see much sense doing it for local builds. Also, I'd generate the file just before the image file is published in Dockerhub (do we currently publish the image when the build fails?).

Kind regards,
Sebastian Brudzinski.

--
You received this message because you are subscribed to the Google Groups "OpenLMIS Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev...@googlegroups.com.
To post to this group, send email to openlm...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/5db41fbb-a87f-4eb2-b554-fe0a675188f7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Paweł Lal]

Thanks for your feedback Sebastian.

The idea of having service name in the build number sounds good. The timezone in build number is a little problematic, I thought about GMT as I wrote in my previous message.
Easier solution is combining only the service name and unique number (integer >= 1) e.g.
requisition-service #23 (similar to Jenkins numbering)

The version file will only be generated for Jenkins builds. Local builds as you said aren't needed, I advised to depend on Jenkins files just in case someone would change version locally and push it to repository to prevent conflicts.
Would it be a problem to call git push after successful build? I'm not sure if it won't trigger another Jenkins build.

Best regards,
Paweł Lal

[Rich Magnuson]

A few thoughts:

 

I agree with Sebastian on the build number:  let’s go with the incremental build number without a reset.  As milestones near, the build # is often used in conversations, issue numbers, etc.

 

Regarding the build/version file itself, here’s one way I’ve seen it done:  the file named “VERSION” exists in source, and its contents read like a template, e.g.:

Build:  $BUILD$

Branch:  $BRANCH$

Timestamp:  $DATE$

Version: $VERSION$ // or, this is the current value of the service/product and is updated manually.  It is from this file that the existing ‘service signature’ API call gets its service version # from

 

The dev build environment simply ignores this file.  The official build environment, during compile time, substitutes in the correct values.  This could be a gradle task that simply is not run on the dev environment, but is included on the Jenkins config.   What do ya’ll think?

 

Overall, I see the VERSION file referenced directly (e.g. which service did I just download?), and used programmatically to show the typical “Help-About” information in the application, and possibly to check for compatibility, etc.

To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/bfa72732-d850-47af-8ced-de6315a0fa31%40googlegroups.com.

[Paweł Lal]

Thanks for your response Rich.

The idea sounds good, I would add Service field to the template, to separate build number from service name (might be useful in "Help" information).
I also found that Jenkins keep environment variables with branch name and build number so passing them to gradle shouldn't be a problem.
This way, the service build number will always be equal to Jenkins build number which is quite reasonable.

As you mentioned, the version number can be updated manually, in that case, I would treat service name the same way.
What do you think?

Best regards,
Paweł Lal

To post to this group, send email to openl...@googlegroups.com.

[Rich Magnuson]

Hi Paweł, sounds good to me. 

To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/270a6e25-6ad9-42d9-9681-4a2d81c004a1%40googlegroups.com.

[Paweł Lal]

Thanks Rich,

I wonder what should happen if the version file is not generated (exists only as a template). Should the endpoint return blank page or version template with its tokens?

Best regards,
Paweł Lal

[Rich Magnuson]

Ah, you are probably thinking about the dev box scenario, and perhaps testing.  I say just return the tokens, so on a dev machine the build # returned from the endpoint is “$BUILD$” or whatever the token is. 

To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/704a2a66-1b02-4046-9124-37397e983848%40googlegroups.com.

[Paweł Lal]

Hello,

I recently finished my work on OLMIS-853. Version file is now included in auth, example and template services (requisition will be updated after build fix).

In a nutshell, every service has it's version_template file. Jenkins build run additional task which changes tokens to appropriate values from passed Jenkins' environment variables.
Generated version file is then saved in jar. Endpoint reads and displays this file and if it's not present in jar (common situation for dev builds), it displays class default values (template).

Version file is available as a build artifact of services on Jenkins, so feel free to have a look and leave a comment.

Best regards,
Paweł Lal