Generator-jhipster: [FEATURE] Add git commit data to /info endpoint

[PierreBesson]

The Spring Boot Actuator Docs §45.7.2 mention a way to add git commit and branch information to the /info endpoint.

As all management endpoints are now secured by default, it would be interesting to have this feature. This is making use of ktoso/maven-git-commit-id-plugin for maven and com.gorylenko.gradle-git-properties for gradle.

It would be very interesting to have this, especially for microservices. Ideally, this info could be displayed in the JHipster Registry.

[PierreBesson]

Any feedback on this ?

Another reason why I would like to add this is to enhance our monitoring (with the JHipster-Console) it would enable to know the which version of an app produced a certain log or metric (This would be achieved by adding an option to add this info to every log). This would be useful for the monitoring of canaries, feature flags, etc...

Moreover I don't see how it could have a negative impact for people that don't want to use it.

[gmarziou]

Well git commit ids are quite unreadable, I'd rather have the artifact version as shown in same doc, this would work for released artifacts only though.

While we are taking about adding data to each log, what about adding the JWT token or user login?

[notflorian]

Is it possible to add both, version and commit id? And what about other SCM like SVN or Mercurials? Either way, I'm ok with this change. ;)

[PierreBesson]

OK, by default, adding those 2 lines to the pom:

            <plugin>
                <groupId>pl.project13.maven</groupId>
                <artifactId>git-commit-id-plugin</artifactId>
            </plugin>

Will add this to the /info

{
    git: {
        branch: "master",
        commit: {
            id: "191793c",
            time: "2016-05-17T15:49:03+0200"
        }
    }
}

@gmarziou, Initially, I also wanted to have the git tags but it's not provided by Spring boot by default so we have to add some code to do it... But actually, it might be cleaner to use the artifact pom as you suggest. It would also support other SCM.

We could try out the #property# maven substitution instead of @property@ that was used by @deepu105 on #3587. If it could work it would be awesome. Just adding something like
info.version: #project.version# would be enough to have the data show up in /info

[gmarziou]

Yes this is what is used in Spring Boot Admin dashboard : http://codecentric.github.io/spring-boot-admin/1.3.0/#show-version-in-application-list

[deepu105]

I think having the required info in the application.yml with property
replacement is the easiest way to do this and IMO a good way with less
overhead and side effects
On 18 May 2016 00:47, "Gaël Marziou" [email protected] wrote:

Yes this is what is used in Spring Boot Admin dashboard :
http://codecentric.github.io/spring-boot-admin/1.3.0/#show-version-in-application-list

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/jhipster/generator-jhipster/issues/3574#issuecomment-219779920

[PierreBesson]

Property replacement seems to be the way to go. I didn't manage to insert git information with property replacement with git data from the git-commit-id-plugin. But I guess as a minimal default config for /info we could simply add this to the application.yml:

info:
    project:
        name: #project.name#
        version: #project.version#

[PierreBesson]

OK, the reason this is not progressing is that I have been stuck for making it works with gradle. Can someone help me. This is my current commit on my branch: https://github.com/jhipster/generator-jhipster/commit/2524e32a8e4d0a6af950b074f2ea69ab5eff2bca

[deepu105]

You seem to be doing it correctly. What is the error your seeing? Or does
it work if you define the artifactId and version in the .dev and .prod
files directly?
On 15 Jun 2016 20:29, "Pierre Besson" [email protected] wrote:

OK, the reason this is not progressing is that I have been stuck for making
it works with gradle. Can someone help me. This is my current commit on my
branch: 2524e32
https://github.com/jhipster/generator-jhipster/commit/2524e32a8e4d0a6af950b074f2ea69ab5eff2bca

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/jhipster/generator-jhipster/issues/3574#issuecomment-226172450,
or mute the thread
https://github.com/notifications/unsubscribe/ABDlF0g35Meslofp0dDolixKF8Fvj-MFks5qL_AKgaJpZM4IbS6g
.

[PierreBesson]

@deepu105, I'm not seeing any error but it doesn't do what I want it to do... The result is that the /info endpoint return an empty JSON.
I tried defining those property in the gradle/profile_dev and it worked but I don't know how I can retrieve the version defined in build.gradle.

[deepu105]

I guess there is way to do it, i have done something similar once. Ill try
to dig that up and let you know
On 16 Jun 2016 01:11, "Pierre Besson" [email protected] wrote:

@deepu105 https://github.com/deepu105, I'm not seeing any error but it
doesn't do what I want it to do... The result is that the /info endpoint
return an empty JSON.
I tried defining those property in the gradle/profile_dev and it worked
but I don't know how I can retrieve the version defined in build.gradle.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/jhipster/generator-jhipster/issues/3574#issuecomment-226254550,
or mute the thread
https://github.com/notifications/unsubscribe/ABDlF8u_pjRL2YZdWxrR_9zbjgJi-PKOks5qMDIwgaJpZM4IbS6g
.

[gmarziou]

I tried it on a project and so far I found it difficult to use artifact version for /info in microservices context because application properties are stored in registry and so cannot benefit from injection during build phase. I thought I could just use bootstrap.yml but I prefer to have it external rather than bundled into service jar file, so that I can change settings.

Finally, I think there could be 2 options:

1. Put version in bootstrap.yml bundled into jar file and use external bootstrap-prod.yml for properties that you want to configure like eureka/ config server
2. Let the app read the META-INF data from the jar and build info programmatically

One thing to note is that Spring Boot 1.4 may help us here with the InfoContributors :

• GitInfoContributor exposes git information if a git.properties file is available.
• BuildInfoContributor exposes build information if a META-INF/build-info.properties file is available

I guess this should work with both maven and gradle

[gmarziou]

Just tried with maven, this is so easy.
I'll make a PR.

http://127.0.0.1:8080/management/info

{
    "build": {
        "version": "0.0.1-SNAPSHOT",
        "artifact": "mono",
        "name": "Mono",
        "group": "com.mycompany.myapp",
        "time": "2016-08-11T22:23:44.000+0000"
    }
}

[PierreBesson]

Very nice, I like how this solution adds no code at all. I was actually waiting for SB 1.4 to go forward with this feature. @gmarziou I will do the same things you did for build-info with git.properties except that it should be restricted to some properties as not everyone will want to have the author name, etc...

[PierreBesson]

I have made progress with the git info. I created a sample project where I add only the git describe (following the format: Tag-nbCommitSinceTag-CommitId) and the git branch fields as those seemed to be the most useful.

In the end I obtain this when querying the /info endpoint:

  "git" : {
    "commit" : {
      "id" : {
        "describe" : "1.0.0-1-g45fe9da"
      }
    },
    "branch" : "master"
  },
  "build" : {
    "version" : "0.0.1-SNAPSHOT",
    "artifact" : "micro-1",
    "name" : "Micro 1",
    "group" : "com.mycompany.myapp",
    "time" : "2016-08-16T20:10:38.000+0000"
  }

I have also managed to add some of these values to the logs forwarded to logstash and have them show up in Kibana. In my sample I added the following properties to the logs:

• Maven build version
• Maven build time
• Git describe
• Git branch

This will be very useful for monitoring with the Console (telling appart 2 versions of the same service). But I'm open to suggestion about what property is really needed here, maybe 4 of them is too much.

I will submit this as a PR once #3970 is merged.

[gmarziou]

I have also managed to add some of these values to the logs forwarded to logstash and have them show up in Kibana

Do you mean they get added to each log statement or only once when application starts up?

[PierreBesson]

To each log statement so we can filter the logs by version.

[gmarziou]

Yes it's a benefit for the 2 versions use case but I'm getting concerned about all the payload we carry with each log statement. With this 4 fields, we'd add about 150 bytes to each statement.

[PierreBesson]

@gmarziou, then lets add only 2 fields the artifact version and the git commit to the logs.
I kind of insist on having the git info here as it was the initial idea and it's important for what comes next :smile: ...

We also need to fix the build-info thing for gradle.

[atomfrede]

@gmarziou @PierreBesson What was the problem with gradle's build info? I've just add buildInfo() to springBoot section in build.gradle and when executing bootBuildInfo the following files under build/resources/main/META-INF/build-info.properties gets created:

#Properties
#Mon Aug 22 21:13:43 CEST 2016
build.time=2016-08-22T21\:13\:43+0200
build.artifact=jhipster
build.group=
build.name=jhipster
build.version=unspecified

Edit: I think the problem is this: processResources.dependsOn cleanResources. So when processing resources all resources are deleted before. I think there was a specific reason why we added the resource cleaning, but don't remember right now :(

[gmarziou]

Great, thanks.

[raphaelbrugier]

Hi,

I was looking for this feature (with maven) but realized you reverted it a couple of days after merging the PR #4018
in https://github.com/jhipster/generator-jhipster/commit/b1ee195b580a67a27a37d1be266a7dc635c1d69b

@PierreBesson Do you remember why?

I will add it manually to our pom.xml - but I was curious to know the reason.

[PierreBesson]

@rafaelbrugier it got reverted as it caused a bug for gradle when the git repo was not initialized (actually a null pointer in the gradle git commit plugin). I think the issue has been fixed since but I got distracted by other things.

Would you like to try to submit a PR to put back the feature in JHipster ?

[raphaelbrugier]

Thanks for the clarification!
I'll try to do a PR in the coming days.