Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Status API] Add build_hash for non-distributable deployments #67946

Open
sorenlouv opened this issue Jun 2, 2020 · 2 comments
Open

[Status API] Add build_hash for non-distributable deployments #67946

sorenlouv opened this issue Jun 2, 2020 · 2 comments
Labels
Team:Core Core services & architecture: plugins, logging, config, saved objects, http, ES client, i18n, etc

Comments

@sorenlouv
Copy link
Member

Currently build_hash is XXX...X for non-distributable deployments of Kibana:

image

Would it be possible to fall back to the actual git version by changing this:

buildSha: isKibanaDistributable ? pkg.build.sha : 'XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX',

To something like:

const currentCommitHash = () => exec('git rev-parse HEAD')
// ...
return {
  buildSha: isKibanaDistributable ? pkg.build.sha : currentCommitHash(), 
}

For development purposes we have dev clusters deployed directly from source, and having the same information available as with distributables would be very helpful.

@sorenlouv sorenlouv changed the title [Status API] Add build_hash to status endpoint [Status API] Add build_hash for non-distributable deployments Jun 2, 2020
@sorenlouv sorenlouv added the Team:Core Core services & architecture: plugins, logging, config, saved objects, http, ES client, i18n, etc label Jun 2, 2020
@elasticmachine
Copy link
Contributor

Pinging @elastic/kibana-platform (Team:Platform)

@pgayvallet
Copy link
Contributor

pgayvallet commented Jun 3, 2020

Even if only in development mode, I've got mixed feeling about invoking git directly from Env. It's also leading to hard to mock value in test environment. OTOH I don't really see any risk if properly wrapped in a try/catch block with fallback to the actual XXX...

Anyone else got a stronger opinion?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Team:Core Core services & architecture: plugins, logging, config, saved objects, http, ES client, i18n, etc
Projects
Development

No branches or pull requests

3 participants