Additions for automated deployments to bintray via travis-ci #82
Conversation
.travis.yml
Outdated
| language: java | ||
| install: true | ||
| script: | ||
| - ./gradlew clean check generatePomFileForXrpcMavenPublication publishToMavenLocal |
There was a problem hiding this comment.
I would make this clean check test (unless check subsumes test), and put the artifact-generation tasks in before_deploy.
There was a problem hiding this comment.
moved the publish tasks to before_deploy
|
@jkinkead it is wise to avoid a specialized release branch if possible. any shared branches add to the complexity of the lifecycle and merge process. i would recommend doing a release on every successful merge to master. this requires each PR to include CHANGELOG and set the new version if needed. the version could also be auto incremented based on a Major, Minor, Patch indicator set by the PR creator... this would also require automatic Github Release using API... I wouldn't recommend this approach for larger projects like kubernetes or the like, but for a smaller library like this it makes sense to me at least. |
|
Right now, fully-automated builds aren't happening (it's been hard enough to get travis building). It might be a good next-step, but I'd like to keep the discussion in the context of this current change. The issue here is that the current approach requires that, for a release to happen, the person running a release needs to have push permissions to It DOES add complexity, since it requires something like:
Instead of:
The question is: Is the added complexity above worth the ability for non-maintainers to deploy? |
* Move publish tasks to `before_deploy` section of travis-ci configuration.
|
I think at this point the added complexity adds marginal value. I've added #83 to discuss the release branches, but personally I don't think this should be a blocker for this PR. As this PR currently stands, we at least get all future PRs built and tests run against them and just the version updates need to be done by a github |
|
SGTM. Mostly I'd like for occasional contributors to be empowered to get their patches out without having to bother an admin. |
|
@jkinkead given the sequence you've listed above, if scripted and the fact that the release branch is a temporary branch it should do the trick... |
…om#82) * Additions for automated deployments to bintray via travis-ci * PR Feedback * Move publish tasks to `before_deploy` section of travis-ci configuration.
No description provided.