Release process: publish more artefacts

[bzz]

As part of release process, we need to add publishing:

• binary artefact to the GH release (at least linux, other platforms Release process: publish MacOS binaries too #184)
• docker image \w appropriate version number to https://hub.docker.com/r/srcd/code-annotation/

artefacts.

[smacker]

Why only Linux? It works fine on macOS too.

[dpordomingo]

Binaries should be pushed by #130
I reviewed the drone config and I realized that it was not listening for tags. I just enabled the tag hook.
I'll release a v0.0.2 on Monday and confirm if it worked

[bzz]

Why only Linux? It works fine on macOS too.

Makes sense, updated PR description.
Everything beyond our current production env which is on linux is a nice to have at this stage though.

[dpordomingo]

Linux binaries were pushed to the v0.0.2 release

what's next?

• ensure the version is properly used in the artifact name (it was not available in drone)
• confirm if macOS binary can be generated and pushed too, and do it if so
• analyze docker image requirement

[dpordomingo]

@bzz docker image is already available at https://hub.docker.com/r/srcd/code-annotation/tags/

If we'd use prod env the docker image tag would be the git tag; since we're using staging env, the docker image tag is defined by the commit hash.

[carlosms]

Here src-d/ci#57 src-d/ci#58 is my attempt to fix

ensure the version is properly used in the artifact name (it was not available in drone)

[bzz]

Nice!

I belive @dpordomingo also might want to close this issue (as both, binaries and docker are available in 0.0.2) and open a new separate ones, about docker artifact naming and a binaries for other platforms.

[smacker]

I would suggest to use Travis for release images/binaries as we do in other projects. And keep drone only for deployment.

[dpordomingo]

we're already using drone.io for pushing docker images, so for reusability, we can use it for delivering the release artifacts too.
If so, this issue would be solved by #183