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

[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!

[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