Provide a memo about releasing

[wu-sheng]

I think we should provide a memo or guides about releasing lib in opentracing-contrib, step by step, like what files need be added, what need be changed, and who should be asked to auth? And

Many people have no experiences in releasing org-based lib, and want to contrib codes in opentracing-contrib, will face this problem eventually.

@sjoerdtalsma, you have attempted to do that in these days, can you help on this? Add a Release-Guide.md in this repo, I suppose.

btw @bensigelman

[wu-sheng]

@pavolloffay, I think maybe you can assist on this.

[sjoerdtalsma]

Once succesfully released, I am willing to assist you on this. Maybe the merged pull-request https://github.com/opentracing-contrib/java-globaltracer/pull/6 can serve as a starting point for your document? It's the reason I haven't deleted my private branch for that pull request yet :wink:

[wu-sheng]

@sjoerdtalsma , you can start where you like:) We work on this for new incoming contributors. 👍

Wait your work done.

[pavolloffay]

Release guide will probably differ from language to language. For java I was thinking about some parent pom with release plugin, if somebody would be interested.

I can create a PR with a readme (RELEASE_GUITE_JAVA.md) describing the steps + minimal pom.xml.

[wu-sheng]

Release_guite_java.md could be the first release guide. Let's do this.💪💪

[pavolloffay]

First thing to consider.

in java we reference release guide from ot-java. Keep in mind that if that changes this would have to be changed probably too.

Second thing to consider:

If the release process is the same for every new contributor (at least for java) he would get access to bintray (so he can edit/delete other artifacts). Wouldn't be better to constrain this and use one account to release to io.opentracing.contrib? E.g. person responsible for releasing ot-java api should provide how-to/access how to release java contrib artifacts (the same applies for other languages).

[sjoerdtalsma]

@pavolloffay I agree that it may be a good idea to have a separation between git access rights (ie. normal 'author') and the bintray / sonatype access account. The release process could stay the same (triggered by tagging a release-xyz) and the releaser would have to one-time add his/her credentials to the .travis.yml file.

That way, documenting this separately would almost feel like overkill as it concerns so few people that way.

[sjoerdtalsma]

Release guide will probably differ from language to language. For java I was thinking about some parent pom with release plugin, if somebody would be interested.

👍 on the parent pom for Java.

[wu-sheng]

@sjoerdtalsma,

add his/her credentials to the .travis.yml file.

This log will exist forever, I suppose. This is a leak of auth management.

@pavolloffay, your idea?

Can we adjust it from a released version tag, already pass the ci, and pubish from local by ones from opentracing-java-team.

The team can be created by @bensigelman.

[sjoerdtalsma]

@wu-sheng

add his/her credentials to the .travis.yml file.

This log will exist forever, I suppose. This is a leak of auth management.

That's no different from the way it is now: encrypted credentials in the .travis.yml file. The leak would actually be less, because it's credentials of less people in this case 😉

[wu-sheng]

@sjoerdtalsma , agree with you, I think the leak is still there. I think in .travis.yml is not a good idea, when some repos got more and more attentions.

I prefer to release at local by particular people. In java-language, maven or gradle is popular and powerful enough, I think it is possible to follow there steps:

1. Pass the init, pull request, discuss, merge... steps
2. Wait repo developers release and tag the repo by guide (assume we already have one.)
3. Developers report to the review/release-team
4. Make sure the repo has travis-ci(compile and test) and passed.
5. Git clone project
6. mvn deploy from their local env, without commit anything to the repo.

@sjoerdtalsma @bensigelman @pavolloffay

[sjoerdtalsma]

Some repo's are bound to change infrequently. I like the simplicity of pushing a release-x.y.z tag and having the release work. This requires a certain amount of one-time setup by the original author. The whole mvn deploy with SSH keys etc. is also non-trivial and may cause headaches if the original author is not available to perform releases...

About the credentials; these can also be stored in the travis-ci settings (on the server), making the encrypted variables at least not visible to others (travis advises to store them in the .travis.yml if they vary accross branches, which ours don't).

[wu-sheng]

I understand your concern about the original author is not available to perform releases.

But the most important problem is, many repos and many diff original author need release code under opentracing-contrib. Anyone have access to release their own repo, also have access to any other repo under opentracing-contrib. If we don't have a mechanism to manage, we will face a chaos.

SSH keys, used in mvn, can be stored in their local setting.xml, if exist release-team member.

[pavolloffay]

I would prefer to have all travis configuration in one place. It makes CI process transparent and easy to manage. From my point this is a big advantage over other CI systems.

This log will exist forever, I suppose. This is a leak of auth management.

It's encrypted. https://github.com/travis-ci/travis-ci/issues/2982#issuecomment-64438280.

As the release is done by travis and can be performed by people who have push rights. It might be good to use credentials of @bensigelman or anybody from contrib org who is "owner" and can create/manage any repo.

[wu-sheng]

Thank you for sharing about travis-ci encrypted. The encrypted key can be removed or disabled by authors, am I right?

Maybe, we can operate like this: when the author need release the repo, they ask @bensigelman or anybody from contrib org for the encrypted credentials (keys), rather than the jcenter manager authority, and contrib org can disable it after release.

Is this operable? @pavolloffay . If yes, which keys are need for releasing?

[wu-sheng]

All these keys?

 # Ex. travis encrypt BINTRAY_USER=your_github_account
 # Ex. travis encrypt BINTRAY_KEY=xxx-https://bintray.com/profile/edit-xxx --add
 # Ex. travis encrypt GH_TOKEN=XXX-https://github.com/settings/tokens-XXX --add
 # Ex. travis encrypt SONATYPE_USER=your_sonatype_account
 # Ex. travis encrypt SONATYPE_PASSWORD=your_sonatype_password

Correct me if I am wrong. 😊 @pavolloffay For example, if I want to release https://github.com/opentracing-contrib/java-hprose, following #7 and our discussions, I should do there:

1. add all three files and pom.xml
2. ask to you ( I assume you have auth ) for these keys. What is your meaning about These need to be re-encrypted and added to .travis.yml?
3. push all these files
4. tag by git. Can I do this by github web-ui?
5. wait ci

[sjoerdtalsma]

You need GH_USER too, apparently as it is used in .settings.xml

[wu-sheng]

GH_USER is GitHub user?

I want to manage tokens and keys, which are only provided by someone already in opentracing-contrib, rather than using their own.

@pavolloffay @sjoerdtalsma , maybe we add a new release account to do that, instead of using someone 's own account?

[sjoerdtalsma]

In my opinion, the simplest possible scenario for maven builds:
I think the .travis.yml + travis/publish.sh could be the same for Java projects. Combined with a super-pom declaring the correct release plugins, things become really simple!

Let the deployer* enable the Travis job for the repo and add release credentials.

*) deployer = person with admin rights on the github repo and deploy rights on bintray + maven central.

[bhs]

Just wanted to mention: I am watching this discussion but am far from an export in Maven-related matters and won't have much to add in terms of mechanics. Let me know if there's anything I can do to help, structurally, from the OpenTracing side.

I definitely would like to see the best practices here distilled into a simple recipe/document in opentracing-contrib somewhere.

[pavolloffay]

Let's summarize:

In order to do the first release:

1. create PR based on java_guide, which includes rights to bintray/sonatype, review+merge
2. switch to master and push tag

The only concern I have about this is granting access to bintray/sonatype, as someone could release/rewrite ot-java artifact.. Correct me if I'm wrong.

In order to avoid granting permission to bintray/sonatype it would be possible to have a "release" user which would be used across contrib repositories. Then "owner" (@bensigelman) of the user would have to push encrypted variables to .travis.yml.

I'm fine with both of these. It's just something I have in mind.. (there are pros and cons for both approaches).

[sjoerdtalsma]

@pavolloffay I think both your concerns are mitigated in the case of the release user (could be one of us for the moment) as per my comment above:

Let the deployer* enable the Travis job for the repo and add release credentials.

That would have two advantages:

1. No github admin rights for the repo needed by contributor for creating travis-ci job.
2. No release credentials in git period (this still is something I feel strongly about and I wish I'd read more about security on travis before I initially pushed my credentials).

[wu-sheng]

+1 @sjoerdtalsma Add release credentials on travis.ci. Maybe you can provide a config snapshot on travis for helping.

Sorry, you two guys. I am too busy these days, an have no time on continuous check. I will do that as soon as I jump up.

[sjoerdtalsma]

@wu-sheng I'd love to help, but I'm not sure I understand what you're asking. The travis job needs to be enabled in travis (checkbox). Then, the credentials need to be added (I suggest GH_USER plaintext so others can see whose credentials they are, the rest encrypted).

The .travis.yml stays exactly the same, except the env global part with all credentials is removed.

[pavolloffay]

@bensigelman @wu-sheng I think this can be closed. https://github.com/opentracing-contrib/meta/pull/7 is merged.

[wu-sheng]

Thank you very much. I am busy on my new born baby these days. 😅 Sorry.

[sjoerdtalsma]

@wu-sheng Congratulations!

[wu-sheng]

@sjoerdtalsma Thanks 💪