Improve development and release workflow

[Galileo-Galilei]

The development workflow can be updated to adress some current issues:

• update contributing process (PR to develop):

  • _add a contribution section to mention contributors: @kaemo @akruszewski I feel your name should be mentioned as your contribution grow more and more -> I have added a "hall of fame" badges with the number of commit of the most active people of the repo. Is it sataisfying? What other solutions would you prefer?
  • force the CI to fail under 100% test coverage: several recent PR have broken coverage (mainly Create a MlflowMetricDataSet #9 but I had spotted breaking the 100% coverage before) (EDIT 2020-09-26)For now, I don't add the --cov-fail-under=100 flag to the "test" step in the build workflow because it will malke all CI fail until we add all the missing tests. I mark it as resolved and add it after the next release. I think that the codecov bot gives far enough information to take decision to merge A PR with the implications in mind.
  • update the coverage to a dedicated third party (codecov? I don't have any preference here, an idea?) to identify more easily the coverage breaking PR.

• update release process both in the documentation and in the CI (PR to master from develop):

  • use an action to create a release in the github repo (if possible taking beeing fed automatically by the changelog, maybe create-release
  • fix the deployment to pypi and move to a public action (maybe gh-action-pypi-publish
    )
  • change the trigger of the worflow (closing a PR even if dismissed currently triggers the pipeline: it should only be triggered when a merge on master is completed).

Do you have any other suggestion @kaemo and @akruszewski ?

[turn1a]

I absolutely agree with all the points.

I'm not sure what coverage tool would be best to use. I know CircleCI is used often for Python open-source projects for many CI/CD tasks. It allows running tests on different platforms, creating coverage reports, building packages and deploying them so it might be a good shout. It could also cover releasing on PyPI. That would, of course, require rewriting our GitHub actions completely and moving them to CircleCI.

[Galileo-Galilei]

Let's add this to the issues to adress when we're having a call.

For the record, I think we should be pragmatic here and keep using github actions on the short term (I guess it will be easier/faster to add the actions I suggested to the existing github workflows rather to rewrite the CI even if it is not difficult, but please go ahead if you really want it 😉 ). CircleCI is definitely one of the most used, let's keep it on the list of potential tools.

[Galileo-Galilei]

I added the following items to the to do list:

• add templates (inspired from kedro's) for the issues / PR
• some README improvements and badges for clarity
• change the matrix in CI to test also on windows and macos

[Galileo-Galilei]

I move the different requirements files from requirements/_requirements.txt to extra-requires in setup.py to make install easier to remeber (pip install kedro_mlflow[docs] or pip install kedro_mlflow[tests])

[Galileo-Galilei]

I suggest to remove the unecessarily compelx workflow of merging on develop and then on master. Since I don't support 2 different versions at the same time, using only the master branch as the reference and release directly from it will make the CI simpler.