opentracing-contrib / meta

A meta-repository for OpenTracing contributions
Apache License 2.0
35 stars 16 forks source link

Provide a memo about releasing #6

Closed wu-sheng closed 7 years ago

wu-sheng commented 7 years ago

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 commented 7 years ago

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

sjoerdtalsma commented 7 years ago

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 commented 7 years ago

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

Wait your work done.

pavolloffay commented 7 years ago

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 commented 7 years ago

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

pavolloffay commented 7 years ago

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 commented 7 years ago

@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 commented 7 years ago

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 commented 7 years ago

@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 commented 7 years ago

@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 commented 7 years ago

@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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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

wu-sheng commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

@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 commented 7 years ago

+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 commented 7 years ago

@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 commented 7 years ago

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

wu-sheng commented 7 years ago

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

sjoerdtalsma commented 7 years ago

@wu-sheng Congratulations!

wu-sheng commented 7 years ago

@sjoerdtalsma Thanks 💪