publish aar to bintray

[ortex]

Publish aar to bintray #19

Current release workflow:

• make sure in 'build.gradle' file right version has been set, e.g. 0.0.1
• make github release with that version, e.g. v0.0.1
• travis will run release stage and publish artifacts to bintray

I've added env variables to travis to publish into https://bintray.com/roc-streaming/maven repo

[gavv]

Great! I'm no good in gradle, so no real review from me, just a few questions / suggestions:

• Could you please also update README? I think we need two new sections: 1) for developers - briefly describe release workflow; 2) for users - add URL to the bintray repo and describe how to use it. The latter may be done later though.

• Did you consider gathering the version in gradle from git?

• Will it work fine if a single tag is built multiple times? Actually two cases here: 1) a tag is rebuilt; 2) a tag is force-pushed to point to another commit and rebuilt.

[gavv]

We also can add bintray badge to README :)

[ortex]

I'll add bintray badge, url to the repo, and how to use it in another MR after the first release.

Did you consider gathering the version in gradle from git?

No, I don't, actually. I don't saw such practices in java world.

Will it work fine if a single tag is built multiple times? Actually two cases here: 1) a tag is rebuilt; 2) a tag is force-pushed to point to another commit and rebuilt.

It depends. If the library with this version was published in bintray, then the second publishing attempt will fail. Bintray forbids updating artifacts.

[ortex]

Could you please also update README? I think we need two new sections: 1) for developers - briefly describe release workflow; 2) for users - add URL to the bintray repo and describe how to use it. The latter may be done later though.

release workflow description added

[ortex]

Did you consider gathering the version in gradle from git?

I guess I can try this approach

[MatteoArella]

Great! I also agree with the continuous deployment approach of getting the version from git tag (for example by using https://github.com/palantir/gradle-git-version gradle plugin).

In both cases (with gradle hard-coded version or with git tag version) we have to differentiate versioning from pure roc-java releases (JAR artifacts) to android releases (AAR artifacts). Any thoughts about that?

Secondly, in the travis Release stage maybe we can avoid rebuilding android artifact (since it's already done during previous Android stage) using travis workspaces https://docs.travis-ci.com/user/using-workspaces (even though they are currently still in beta); in this way, during android build phase, a new workspace is created caching AAR artifact, then the same workspace is used in Release stage letting gradle to just publish the already built artifact.
Anyway we can go with your solution for now and add the workspace feature in a different issue if you agree with this idea.

Lastly, for authenticity reasons we should digitally sign the artifact with a GPG key (adding version { gpg { sign = true } } to bintray.pkg closure), using Bintray default GPG key or with our generated GPG key.

[ortex]

Great! I also agree with the continuous deployment approach of getting the version from git tag (for example by using https://github.com/palantir/gradle-git-version gradle plugin).

Now version gathering from git tag.

In both cases (with gradle hard-coded version or with git tag version) we have to differentiate versioning from pure roc-java releases (JAR artifacts) to android releases (AAR artifacts). Any thoughts about that?

I thought the easiest way is releasing jar and aar together

Lastly, for authenticity reasons we should digitally sign the artifact with a GPG key (adding version { gpg { sign = true } } to bintray.pkg closure), using Bintray default GPG key or with our generated GPG key.

Configuration added.
I suppose we can use Bintray default GPG keys?

[gavv]

In both cases (with gradle hard-coded version or with git tag version) we have to differentiate versioning from pure roc-java releases (JAR artifacts) to android releases (AAR artifacts). Any thoughts about that?

@MatteoArella Can we just build and publish two artifacts from one tag? Are there any caveats?

Secondly, in the travis Release stage maybe we can avoid rebuilding android artifact (since it's already done during previous Android stage) using travis workspaces https://docs.travis-ci.com/user/using-workspaces

Sounds good! Could you create an issue for that?

And as for force-pushing tags which I mentioned above, maybe we can just forbid it by marking them protected in github repo settings.

[gavv]

I'll add bintray badge, url to the repo, and how to use it in another MR after the first release.

Cool, added this to #13.

[MatteoArella]

I suppose we can use Bintray default GPG keys?

Yes

[MatteoArella]

In both cases (with gradle hard-coded version or with git tag version) we have to differentiate versioning from pure roc-java releases (JAR artifacts) to android releases (AAR artifacts). Any thoughts about that?

@MatteoArella Can we just build and publish two artifacts from one tag? Are there any caveats?

Yes surely we can use the same tag for both releases. The only caveat that comes in my mind would be for example in case new modifies are made for something related only to pure java release (for example something related to build system); in that case they would trigger also a new android release. Anyway that would not be a real problem.

Secondly, in the travis Release stage maybe we can avoid rebuilding android artifact (since it's already done during previous Android stage) using travis workspaces https://docs.travis-ci.com/user/using-workspaces

Sounds good! Could you create an issue for that?

Yes of course.

[MatteoArella]

Great!

Lastly, @gavv after cloning roc-toolit should we do a git checkout on its latest release (in order to be sure to use the same android binding version)?

[gavv]

after cloning roc-toolit should we do a git checkout on its latest release (in order to be sure to use the same android binding version)?

Indeed, but I think first we need to choose how to map bindings version to toolkit versions and thus determine what versions we want to test. BTW, we'll probably want to test bindings with multiple versions of toolkit on CI (according to our mapping).

[gavv]

@ortex Please rebase on fresh master, it should fix the build.

[gavv]

+1 from me

[gavv]

@ortex does it also resolve #27?

[ortex]

@ortex Please rebase on fresh master, it should fix the build.

done

@ortex does it also resolve #27?

I guess so, let's see what @MatteoArella thinks.

[MatteoArella]

@ortex Please rebase on fresh master, it should fix the build.

done

@ortex does it also resolve #27?

I guess so, let's see what @MatteoArella thinks.

Yes 👍