allow travis to push releases on PyPi #12
Conversation
|
Note: travis shows some warnings regarding the current configuration format. |
|
Good point. I'll add a note in the CONTRIBUTING.rst file. About testing the release process on a fork, I didn't want to setup a travis project specifically for this sole change/test. |
|
Thanks @ziirish, we could set it to push to PyPi test server and then push a dev tag ? |
|
I have updated the version and set it to |
|
I just tried to add a tag in order to validate travis pushes our release on test.pypi.org, and... it's working \o/ So I rolled back the changes so the .travis-ci.yml file is setup to push on pypi.org |
|
Brilliant work @ziirish 😊 My last thing before I'm happy with a merge is to check the behaviour change from the |
|
I put I removed the publish part so I can still use |
|
Ah ok that makes sense thank you explaining 😊 I know it's nit-picking but would you mind adding an explanation of that to the commit description? It's not clear just form the short commit message why that change is in there. We've run into issues before with old commits not adequately explaining a change and it's held us back from making further changes due to a lack of understanding. It would be good for the community if we could avoid that on the new fork 😊 You can edit the commit message with |
|
What information would you like to have in the commit message? I didn't find that information relevant because almost no-one will be using it anyway since we automated the release process through travis. I also think that we can find the detailed explanation here in the PR comments and the link will be attached to the merge commit so really I don't feel the need to have top rock commit messages. We are a community/volunteer project. I'd like it to stay "accessible" to everyone who'd like to contribute. If we enforce a high contribution requirements that bring no value to the actual project we'll loose opportunities to grow. |
|
Yes the change to I absolutely agree that the project should be accessible, however I disagree that commit message quality is not desirable - commit messages are not a high bar to entry. Being accessible is allowing the community to contribute and (as the core maintainers) to assist people to do so at a reasonable level of quality - not to stop the contributions by any means. IMO it's even more important in a community driven project to maintain a useful commit history and the knowledge of the project is, by definition, shared and distributed amongst many people. In this particular case I admit that I am nit-picking somewhat. However, I'm doing so in order for us to start off well and set examples for the community going forward. |
This change allows Travis-CI to build and publish new releases on PyPi.org upon tag additions. The bumpr.rc file has been changed accordingly since we won't use it anymore to push new releases directly, but we may still use it to prepare new releases (ie. edit the CHANGELOG, README, etc.)
|
done |
|
Thank you @ziirish , I appreciate it (and this PR of course). This looks great to me now and will be incredibly useful! I think this discussion has been helpful to start getting a feeling for our expectations around ongoing development of the project. I appreciate you challenging my request for the change to the commit message as it made me explain my reasoning properly and to articulate my thoughts around accessibility. I should have said those up front along with the request - I apologise. Let's continue on Gitter as I think it'll be good to talk it through a bit more 😄 |
addresses #6
Added a token in travis-ci to allow to push releases on PyPi.
I'll need to push a tag in order to test everything is working as expected.