Create the automated release process using googleapis/release-please

[nijanthanvijayakumar]

Proposed changes

• release-please-config.json: Add configuration file with release type set to python, and the changelog path to CHANGELOG.md.
• .release-please-manifest.json: Add manifest file with quinn version set to 0.10.3.
• .github/workflows/release-please.yml: Add workflow file for release-please action
• CONTRIBUTING.md: Add a section to elaborate the "Release and Pre-Release Processes".

Types of changes

What types of changes does your code introduce to quinn?
Put an x in the boxes that apply

• Bugfix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Documentation Update (if none of the other choices apply)

Further comments

• Please refer to the *CONTRIBUTING.md* file to understand how this works. It took a bit of time to test the scenarios and understand how the release & pre-release works.
• @dinjazelena - thanks a tonne for the code.
• Closes the issue feat: Add CI for release and pre-release  #252.

[dinjazelena]

@nijanthanvijayakumar @SemyonSinchenko . It should be on on_push. So basically what happens is when u want to introduce the change to your main branch, most likely from PR or just a single commit. Every time there is commit(or PR), release-please-action is triggered and it searches for pattern in your commit message(PR title) with prefix of fix: or feat: or fix! or refactor! or ci: and many more. Based on your PR title(commit message) release please would create a PR which is using to accumulate and follow all of your changes.

So lets say u have window for releasing, and by that time u made 3 bug fixes added 2 new features, release please keeps all of those changes in your automatic pull request. Once u are ready to merge that automatic pull request created by release please, it would create a Github Release, bump versions in __init__.py, pyproject.toml , update CHANGELOG.md and ideally release your artifact to PyPi.

What release please lacks is using both prelease and release, it promotes trunk based, but it somehow does not allow it to use both of these. So u can automatically create for example release candidates, and then just have a manual workflow to release production version or vice versa.

And ideally u tested this on separate github repo to make sure its all good.

Also release-please-manifest.json, is what is used to track versioning under the hood, so current latest version should be there.

[SemyonSinchenko]

@nijanthanvijayakumar @dinjazelena Thanks for the explanation! Do I understand right, that this workflow make a realease to PyPI? If so, which secrets should be provided?

[nijanthanvijayakumar]

@SemyonSinchenko - this workflow creates a GitHub release as in the screenshot below and I don't think it creates a PyPi release (I might take your help in double-confirming this @dinjazelena?). The only reference to Python I used in this workflow is here.

While creating it, I didn't see any references to PyPi and it worked on the test repo I shared earlier without involving the creation of any secrets.

[SemyonSinchenko]

Can we somehow add a step to the release pipeline that publish in PyPI release or pre-release versions?

[nijanthanvijayakumar]

Can we somehow add a step to the release pipeline that publish in PyPI release or pre-release versions?

Sure can look into it, but did you want that to be done in this PR?

[dinjazelena]

Yeah, so this only creates Github Release, but logically, u would just have additional step in your github action workflow with smth like this

if: ${{ steps.release.outputs.release_created }}
run: |
   poetry publish ...

Here is an example for nmp.

Question is only do you want to create automatic release for pre-releases or for production releases because unfortunately it cannot support both.

[SemyonSinchenko]

Question is only do you want to create automatic release for pre-releases or for production releases

I would have better automated prod-release

[nijanthanvijayakumar]

Question is only do you want to create automatic release for pre-releases or for production releases

I would have better automated prod-release

@SemyonSinchenko - sure. I came across this article, and according to this, one doesn't need secrets to publish to the PyPI repository due to the "trusted publishing" feature. However, as indicated in the image below from the Set up PyPI publishing using GitHub section of that article, Quinn's project author or maintainer must add GitHub Actions as a trusted publisher for that project. Are you or @MrPowers able to do that while I whip up the code for publishing the package to PyPI?

Steps for adding a trusted publisher is documented in this PyPI docs here - https://docs.pypi.org/trusted-publishers/adding-a-publisher/

[nijanthanvijayakumar]

Question is only do you want to create automatic release for pre-releases or for production releases

I would have better automated prod-release

@SemyonSinchenko - sure. I came across this article, and according to this, one doesn't need secrets to publish to the PyPI repository due to the "trusted publishing" feature. However, as indicated in the image below from the Set up PyPI publishing using GitHub section of that article, Quinn's project author or maintainer must add GitHub Actions as a trusted publisher for that project. Are you or @MrPowers able to do that while I whip up the code for publishing the package to PyPI?

Steps for adding a trusted publisher is documented in this PyPI docs here - https://docs.pypi.org/trusted-publishers/adding-a-publisher/

Hello @SemyonSinchenko ! Any suggestions on the next steps?

[SemyonSinchenko]

Sorry, I missed the comment. I will ask @MrPowers