Automatically check if the tool is up to date

[exekias]

We are currently recommending people to install this tool by using go get. I think this is the best approach until we get to some degree of stability in the features it provides (we are not close to this by any means).

It would be nice to have an automatic check when the tools is called that warns you if it's not up to date, and gives you the command to run if you need to update.

This would ensure that developers don't lag behind on tooling, with the confusion that that may cause (ie my integration works in local but fails in CI...).

To avoid degrading the user experience, I think we should only check for new versions from time to time (maybe store the last successful check timestamp into a file) and have a good silent timeout if things are too slow.

We could use the following API to retrieve master branch ref:

turing.local :: integrations/packages/nginx ‹master› » time curl https://api.github.com/repos/elastic/elastic-package/git/ref/heads/master
{
  "ref": "refs/heads/master",
  "node_id": "MDM6UmVmMjY5NjEyNzUzOnJlZnMvaGVhZHMvbWFzdGVy",
  "url": "https://api.github.com/repos/elastic/elastic-package/git/refs/heads/master",
  "object": {
    "sha": "9e6eefab29ae9533a7d387cc62247a77a9ec07ff",
    "type": "commit",
    "url": "https://api.github.com/repos/elastic/elastic-package/git/commits/9e6eefab29ae9533a7d387cc62247a77a9ec07ff"
  }
}
curl https://api.github.com/repos/elastic/elastic-package/git/ref/heads/maste  0.02s user 0.01s system 6% cpu 0.333 total

[elasticmachine]

Pinging @elastic/integrations (Team:Integrations)

[exekias]

There is a small issue we would need to overcome: Retrieving the local commit hash

If the tool was installed with go get it should be present under Go's path: src/github.com/elastic/elastic-package. We should treat the case where we cannot really discover the local hash (ie if the user installed it by other means)

[mtojek]

Let's review possible options.

1. Git tag only

Just tag next commits with versions whenever is good to release a change. With mergify and dependabot in place,
all updates will be automatically pulled into elastic/integrations repository.

Nothing will change for end-users, unless we decide to show notifications in the application that there is a newer
version available. They will have to refresh and rebuild sources as they do now.

2. Use goreleaser to release Linux/Windows/Mac binaries

We can use goreleaser to push new binaries to the Github Releases and store them there. The solution will base
on Git tags, so dependabot will detect new snapshots. Every release will be triggered with a new Git tag.

We can show notifications in the application and provide a direct link to a new binary. I don't think we need to create
a full-blown installer for this.

3. Use docker images

(not sure if 100% possible)

Ok, so this is a bit different approach - elastic-package will be distributed as Docker images. There might be problems
with mounting local directories, accessing docker unix socket (docker, docker compose, kind) and kubectl. I'm not convinced
as it seems to be over-engineering. But there is one benefit - end-users can just re-pull the image and have the latest
available app revision.

4. Depend on the unified release process

Release elastic-package as other artifacts (beats, elatic-agent, etc.) In this case we are part of the unified release
process, so everyday are published new snapshots. Most likely we'll have to align app's version with stack versioning.
Possible drawbacks - we may deal with broken build, blockers, pings from infra, backporting bugfixes, etc.
All of these may cause additional operational load on developers.

---

I think that I prefer the option 1. or 2. We would have our own build/release control and wouldn't depend much on global
release cycle. WDYT @jsoriano?

[jsoriano]

I like options 1 and 2 too, I wouldn't couple this to releases of the stack as in the option 4. I like having pre-built binaries as in option 2, so package developers only need to download elastic-package to start. Docker images may be a nice to have for certain cases, but I would prefer to have binaries first, we may consider option 3 in the future if requested even if we implement 1 or 2 now.

[mtojek]

Ok, so I managed to build and release v0.9.1 , but the version info is invalid:

➜  Downloads tar xvzf elastic-package_0.9.1_darwin_amd64.tar.gz
x LICENSE.txt
x README.md
x elastic-package
➜  Downloads ./elastic-package version
2021/07/16 12:44:48  WARN CommitHash is undefined, in both /Users/marcin.tojek/.elastic-package/version and the compiled binary, config may be out of date.
elastic-package version-hash undefined (build time: unknown)

I will investigate this further.