feat: Add CI for release and pre-release

[SemyonSinchenko]

Feature Type

• Adding new functionality to quinn

• Changing existing functionality in quinn

• Removing existing functionality in quinn

Problem Description

We need a CI for making releases (for example, via release-please) and pre-releases. CHANGELOG should be generated and updated automatically. We are going to strictly follow semver 2.0 starting from quinn 1.0

Feature Description

.

Additional Context

No response

[nijanthanvijayakumar]

Are you okay for me to take up this and give it a try @SemyonSinchenko ?

[nijanthanvijayakumar]

Hello @SemyonSinchenko - thank you for assigning this task to me. I am trying to understand the ask here. Please can you clarify if my understanding is correct? I have created a flow-diagram of my understanding below.

graph TD
    A[PR to main branch] --> B[Trigger a Pre-release job]
    B --> C[Step 1: Build package using release-please GitHub action]
    C --> D[Step 2: Test using poetry pytest or make test]
    E[Push to main branch] --> F[Trigger a Release job]
    F --> G[Step 1: Check the semver if 2.0]
    G --> H[Step 2: Create a release using release-please \`use contributor names etc.\`]

Loading

[dinjazelena]

Hey @nijanthanvijayakumar, so mostly Sem is here referring to how do u release your production ready artifact and also how do u release your development versions or release candidates.

For releasing your artifact from main branch that is production grade, i would say using release-please github actions is amazing. It really automates everything and its very smooth.
Question is how do u want to release your prerelease,dev candidates? Because with release-please it is not possible to push artifacts from feature branches only from the main branches, but since this is also a library, i would say that option is great as well.

In our team, we do have option to release development versions from the feature branches because we have some bigger integration tests that are using this library as well, so we dont want to work on that iteration of 1. merge to main 2. deploy development artifact 3. fix error 4. open again feature branch cycle repeat.
But since u have been working on unit tests and its just a public library i would say that using release please to release production candidates and production version is totally fine in this case.

Difference between development versions(release candidates or pre-release) is that u append suffix like alpha, beta or rc and pypi automatically knows its not stable, so for installing those versions u need user to specifically notify the version pip install quinn==1.1.1.alpha.1 which is perfect for trying out not just by you but also users.

Setting up release please its not so trivial cos they really lack documentation especially for pre-releases.

https://github.com/googleapis/release-please-action
https://github.com/googleapis/release-please
https://semver.org/

I think main question is from where do u want to release your development artifacts and its question to @SemyonSinchenko and @MrPowers

Now as far as how release-please work, u just gotta do the homework :). But basically based on PR title or commit messages it uses https://www.conventionalcommits.org/en/v1.0.0/ to automatically updates version of project, it creates Github Release, it updates version in init.py, or toml and it appends all of the changes in CHANGELOG.

so if your PR title when merging to main is fix: added backward comp based on fix it knows to increment PATCH version of project.
Just open another test repo and check it out, no other way really. Its scary to do it first here haha.

[nijanthanvijayakumar]

Haha thanks for the detailed message @dinjazelena .
I've almost completed my changes for the release-please - assume it's a first-draft from me based on the assumption I've.

But one been thinking of the same question when it comes to pre-releases.

@SemyonSinchenko and @MrPowers - would you like to do a pre-release from a branch like release/*?

[SemyonSinchenko]

@nijanthanvijayakumar It would be cool to have a pre-release. May we do a pre-release from the main branch?

[nijanthanvijayakumar]

Hey @SemyonSinchenko . I was thinking of the following approach. Let me know what you think:

Pre-release:

• Gets triggered when a PR is merged from feature* or develop* branches to release/* or release* (similar to the planning-1.0-release branch).
• The release/* branch is created from the main branch.
• Build the package and create a tag with suffix similar to what @dinjazelena suggested like quinn-1.0.0.alpha.1
• Publish a pre-release info on CHANGELOG.md using the release-please.
• Test that package using Ubuntu image in the same action by running pytests etc.

Once you're happy with the pre-release artefact, create a PR from *release* branch to the main, and upon merge

Release:

• This step gets triggered on push to the main branch.
• Publish the release using release-please.

The only drawback I see from the above is, the PyTests that run when pre-release gets packaged would be the same that gets run when someone creates a PR too. There doesn't seem to be any difference in that.

Let me know what you think of this approach?

[SemyonSinchenko]

Do I understand correctly that it will be a gitfhlow-way with a development branch? Can we instead have only main branch and be able to make releases and pre-releases from it?

[nijanthanvijayakumar]

@SemyonSinchenko - acknowledging your previous comment regarding creating releases and prereleases from the main branch.

I've been trying to finalise this in a test repo of mine but haven't been able to successfully create a pre-release. Even after defining pre-release configs in the config files, it only created regular/normal releases. The documentation on this particular aspect is very little to nothing. However, I came across this particular issue which is marked as a bug: googleapis/release-please-action#925

Let me know your thoughts?

[SemyonSinchenko]

@dinjazelena Hi! May you help us please with a comment above? Thanks in advance!

[dinjazelena]

I agree with @SemyonSinchenko, today with so many tools and libraries available for testing and automating, gitflow just takes too much time and too many branches, so trunk based development is state of art.

Yeah, i was also struggling alot on prerelease, not much documentation, will take a look and come back here. I am coming back from vacation :).

[dinjazelena]

Hey @nijanthanvijayakumar, i just checked how to configure prerelease for beta, alpha or rc. You must use manifest and configuration file in order to set it up.
Here is an small example how to create it:
https://github.com/dinjazelena/test-release-please

Key thing is to find that we need to provide key versioning: prerelease which totally is missing from configuration.

manifest configuration:
https://github.com/googleapis/release-please/blob/main/docs/manifest-releaser.md

[SemyonSinchenko]

@nijanthanvijayakumar Hi! This is issue is the only one blocking us from a new big release. Do you need any kind of help with that issue?

[nijanthanvijayakumar]

@nijanthanvijayakumar Hi! This is issue is the only one blocking us from a new big release. Do you need any kind of help with that issue?

Hey apologies @SemyonSinchenko . Haven't had access to my laptop all these days. The last I tried @dinjazelena suggestion I still remember facing some issues. I'll give it a go once again and let you know if I need a hand. Cheers!

[nijanthanvijayakumar]

@SemyonSinchenko - please find the PR in the references below (kindly ignore the #261 and use #262 as I incorrectly branched from the main branch instead of the planning-1.0-release branch). Please review & let me know if you would like some changes to be done to it. I request you going through the *CONTRIBUTING.md* where I have documented the release process.

Appreciate if you could add me to a slack channel or something if you have for this repo, so that it's easier to converse.

@dinjazelena - thanks once again for the help