[Suggestion] allow to expose the commit id through other ways

[stof]

Using a comment in the HTML works only for HTML websites. This does not play well with other kind of projects (APIs for instance).

Would it be possible to expose the commit id in other ways ? I see 2 potential ways:

• exposing it in a header
• exposing a dedicated API endpoint returning info about the API (and having the commit id as one of the info in the JSON). This solution would of course only be useful for APIs (and especially APIs having such an endpoint already)

[rtyley]

Would it be possible to expose the commit id in other ways ? I see 2 potential ways:

exposing it in a header

That seems reasonable - Prout could read a X-Git-Commit: header (that just happens to be a header name that googling reveals one other person has used before: https://gist.github.com/darashi/114761 )

exposing a dedicated API endpoint returning info about the API (and having the commit id as one of the info in the JSON). This solution would of course only be useful for APIs (and especially APIs having such an endpoint already)

You can already do this!

Prout doesn't require that the commit id is in an HTML comment, or even in any particular format other than being an isolated 40-char hex string - so if you want to keep your API JSON only, just return the hex id as part of a JSON manifest/metadata endpoint, just point to that endpoint your .prout.json, eg like this:

• https://github.com/guardian/membership-attribute-service/blob/8a18590/.prout.json#L3
• https://members-data-api.theguardian.com/healthcheck

[stof]

Great that it already works for the api endpoint. It would be great to improve the readme about the way the commit id should be exposed.

[kaji-bikash]

Prout doesn't require that the commit id is in an HTML comment, or even in any particular format other than being an isolated 40-char hex string - so if you want to keep your API JSON only, just return the hex id as part of a JSON manifest/metadata endpoint, just point to that endpoint your .prout.json, eg like this:

https://github.com/guardian/membership-attribute-service/blob/8a18590/.prout.json#L3
https://members-data-api.theguardian.com/healthcheck

Does it need to be 40-char hex ? since commit ids are completely identifiable within repo by shorter version like

git rev-parse --short master

Again does the endpoint has to return in JSON ?? I am trying to leverage REVISION file written automatically by capistrano deployment tool in ROR project. REVISION file is a text file containing a short SHA1 representation of commit-id at which the deployment happened.

[rtyley]

Does it need to be 40-char hex ? since commit ids are completely identifiable within repo by shorter version like

Prout expects a 40-char hex:

https://github.com/guardian/prout/blob/25e4e5a60/app/lib/CheckpointSnapshot.scala#L42

In principle, you could go shorter, but for all use-cases I'm aware of it's not really any trouble to specify the full commit id (is there a reason why you can't?) - and resolving shorter ids just exposes one possible avenue for ambiguity.

[kaji-bikash]

Yeah I see what you mean by one more avenue of ambiguity . I was only trying to leverage what is given currently by our deployment tool. Had it worked, we would have a poor man's API endpoint under http://ourwebsite.uri/revision.txt spitting out short version 7-char HEX of git commit SHA1.

For the sake of testing, we configured http://ourwebsite.uri/revision.txt to return full 40-char hex in plaintext format. We are getting this in our web-server logs

"POST /api/hooks/github HTTP/1.1" 204 0 "-" "GitHub-Hookshot/7a65dd9"

is that expected output ? does the endpoint has to return in JSON ?? like in your example https://members-data-api.theguardian.com/healthcheck

[rtyley]

does the endpoint has to return in JSON ??

No, so long as the response body contains a 40-char hex, it can be text, html, or json, whatever.

For instance, in the html of https://membership.theguardian.com/ , there's this HTML comment:

<!-- build-commit-id: 5cd2c55008ad32abac7e9fe8a0ac54fc1fd9878a -->

[kaji-bikash]

👍 Super ! Sorry following query might deviate from discussion happening under this thread.

What happens when http://ourwebsite.uri/revision.txt returned commit point that has no .prout.json configured; let's say that is master branch and we are introducing prout by adding to the repository via PR which is still in flight to get merged to master?

"POST /api/hooks/github HTTP/1.1" 204 0 "-" "GitHub-Hookshot/7a65dd9"

Is 204 status code correct in above scenario ?

.prout.json

{
  "checkpoints": {
    "PROD": { "url": "http://ourwebsite.uri/revision.txt", "overdue": "10M" }
  }
}

Repository is correctly configured already to deliver web-hook to on-premise hosted prout.