OpenLMIS build info and build number proposal

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

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.
···

On 01.08.2016 12:16, plal wrote:

Hello,

    Since I started working on [OLMIS-853](https://openlmis.atlassian.net/browse/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

  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+unsubscribe@googlegroups.com.

  To post to this group, send email to openlmis-dev@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?utm_medium=email&utm_source=footer)      . For more options, visit .

https://groups.google.com/d/msgid/openlmis-dev/5db41fbb-a87f-4eb2-b554-fe0a675188f7%40googlegroups.com
https://groups.google.com/d/optout

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

···

On Monday, 1 August 2016 13:55:24 UTC+2, Sebastian Brudziński wrote:

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.

On 01.08.2016 12:16, plal wrote:

Hello,

    Since I started working on [OLMIS-853](https://openlmis.atlassian.net/browse/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

  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?utm_medium=email&utm_source=footer)[https://groups.google.com/d/msgid/openlmis-dev/5db41fbb-a87f-4eb2-b554-fe0a675188f7%40googlegroups.com](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](https://groups.google.com/d/optout).

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.

···

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

On Monday, 1 August 2016 13:55:24 UTC+2, Sebastian Brudziński wrote:

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.

On 01.08.2016 12:16, plal wrote:

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

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
.

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+unsubscribe@googlegroups.com.

To post to this group, send email to
openlmis-dev@googlegroups.com.

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

For more options, visit https://groups.google.com/d/optout.

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

···

On Monday, 1 August 2016 18:52:51 UTC+2, Rich Magnuson wrote:

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.

From: openlm...@googlegroups.com [mailto:openlm...@googlegroups.com] On Behalf Of Pawel Lal

Sent: Monday, August 1, 2016 5:38 AM

To: OpenLMIS Dev openlm...@googlegroups.com

Subject: Re: [openlmis-dev] OpenLMIS build info and build number proposal

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

On Monday, 1 August 2016 13:55:24 UTC+2, Sebastian Brudziński wrote:

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.

On 01.08.2016 12:16, plal wrote:

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

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
.

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
openl...@googlegroups.com.

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

For more options, visit https://groups.google.com/d/optout.

Hi Paweł, sounds good to me.

···

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

On Monday, 1 August 2016 18:52:51 UTC+2, Rich Magnuson wrote:

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.

From:
openlm...@googlegroups.com [mailto:openlm...@googlegroups.com] On Behalf Of Pawel Lal

Sent: Monday, August 1, 2016 5:38 AM

To: OpenLMIS Dev openlm...@googlegroups.com

Subject: Re: [openlmis-dev] OpenLMIS build info and build number proposal

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

On Monday, 1 August 2016 13:55:24 UTC+2, Sebastian Brudziński wrote:

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.

On 01.08.2016 12:16, plal wrote:

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

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
.

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 openl...@googlegroups.com.

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

For more options, visit
https://groups.google.com/d/optout
.

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+unsubscribe@googlegroups.com.

To post to this group, send email to
openlmis-dev@googlegroups.com.

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

For more options, visit https://groups.google.com/d/optout.

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

···

On Tuesday, 2 August 2016 18:36:53 UTC+2, Rich Magnuson wrote:

Hi Paweł, sounds good to me.

From: openlm...@googlegroups.com [mailto:openlm...@googlegroups.com] On Behalf Of Pawel Lal

Sent: Tuesday, August 2, 2016 2:06 AM

To: OpenLMIS Dev openlm...@googlegroups.com

Cc: pl...@soldevelo.com

Subject: Re: [openlmis-dev] OpenLMIS build info and build number proposal

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

On Monday, 1 August 2016 18:52:51 UTC+2, Rich Magnuson wrote:

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.

From:
openlm...@googlegroups.com [mailto:openlm...@googlegroups.com] On Behalf Of Pawel Lal

Sent: Monday, August 1, 2016 5:38 AM

To: OpenLMIS Dev openlm...@googlegroups.com

Subject: Re: [openlmis-dev] OpenLMIS build info and build number proposal

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

On Monday, 1 August 2016 13:55:24 UTC+2, Sebastian Brudziński wrote:

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.

On 01.08.2016 12:16, plal wrote:

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

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
.

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 openl...@googlegroups.com.

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

For more options, visit
https://groups.google.com/d/optout
.

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
openl...@googlegroups.com.

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

For more options, visit https://groups.google.com/d/optout.

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.

···

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

On Tuesday, 2 August 2016 18:36:53 UTC+2, Rich Magnuson wrote:

Hi Paweł, sounds good to me.

From:
openlm...@googlegroups.com [mailto:openlm...@googlegroups.com] On Behalf Of Pawel Lal

Sent: Tuesday, August 2, 2016 2:06 AM

To: OpenLMIS Dev openlm...@googlegroups.com

Cc: pl...@soldevelo.com

Subject: Re: [openlmis-dev] OpenLMIS build info and build number proposal

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

On Monday, 1 August 2016 18:52:51 UTC+2, Rich Magnuson wrote:

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.

From:
openlm...@googlegroups.com [mailto:openlm...@googlegroups.com] On Behalf Of Pawel Lal

Sent: Monday, August 1, 2016 5:38 AM

To: OpenLMIS Dev openlm...@googlegroups.com

Subject: Re: [openlmis-dev] OpenLMIS build info and build number proposal

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

On Monday, 1 August 2016 13:55:24 UTC+2, Sebastian Brudziński wrote:

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.

On 01.08.2016 12:16, plal wrote:

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

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
.

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 openl...@googlegroups.com.

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

For more options, visit
https://groups.google.com/d/optout
.

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 openl...@googlegroups.com.

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

For more options, visit
https://groups.google.com/d/optout
.

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+unsubscribe@googlegroups.com.

To post to this group, send email to
openlmis-dev@googlegroups.com.

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

For more options, visit https://groups.google.com/d/optout.

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

···

On Wednesday, 3 August 2016 17:51:12 UTC+2, Rich Magnuson wrote:

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.

From: openlm...@googlegroups.com [mailto:openlm...@googlegroups.com] On Behalf Of Pawel Lal

Sent: Wednesday, August 3, 2016 2:07 AM

To: OpenLMIS Dev openlm...@googlegroups.com

Cc: pl...@soldevelo.com

Subject: Re: [openlmis-dev] OpenLMIS build info and build number proposal

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

On Tuesday, 2 August 2016 18:36:53 UTC+2, Rich Magnuson wrote:

Hi Paweł, sounds good to me.

From:
openlm...@googlegroups.com [mailto:openlm...@googlegroups.com] On Behalf Of Pawel Lal

Sent: Tuesday, August 2, 2016 2:06 AM

To: OpenLMIS Dev openlm...@googlegroups.com

Cc: pl...@soldevelo.com

Subject: Re: [openlmis-dev] OpenLMIS build info and build number proposal

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

On Monday, 1 August 2016 18:52:51 UTC+2, Rich Magnuson wrote:

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.

From:
openlm...@googlegroups.com [mailto:openlm...@googlegroups.com] On Behalf Of Pawel Lal

Sent: Monday, August 1, 2016 5:38 AM

To: OpenLMIS Dev openlm...@googlegroups.com

Subject: Re: [openlmis-dev] OpenLMIS build info and build number proposal

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

On Monday, 1 August 2016 13:55:24 UTC+2, Sebastian Brudziński wrote:

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.

On 01.08.2016 12:16, plal wrote:

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

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
.

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 openl...@googlegroups.com.

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

For more options, visit
https://groups.google.com/d/optout
.

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 openl...@googlegroups.com.

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

For more options, visit
https://groups.google.com/d/optout
.

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
openl...@googlegroups.com.

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

For more options, visit https://groups.google.com/d/optout.