asyncapi / dotnet-rabbitmq-template Goto Github PK

Reason/Context

I am a frequent user of OpenAPI and use NSwag extensively to manage REST API integrations. NSwag has the ability to customize namespaces, data structures, and output file structure, which is a significant benefit. However, the dotnet-rabbitmq-template project lacks this extensibility feature. Therefore, I would like to request this feature to enhance the dotnet-rabbitmq-template project's productivity and flexibility for AsyncAPI developers in a .NET environment.

Description

To implement this feature, the dotnet-rabbitmq-template project needs to be extended to allow for customization of namespaces, data structures, and output file structure. This change may potentially remove the csproj, appsettings, and other files, which would require more setup by a user to get a working application. As a result, this feature could be considered a breaking change.

To overcome this issue, a migration guide and documentation should be created to help users transition smoothly to the new version of the project. Additionally, backward compatibility could be maintained in the current version of the project for users who do not wish to migrate to the new version.

How will this change help?

This feature will allow users to customize namespaces, data structures, and output file structure to fit their specific requirements. This flexibility will make the dotnet-rabbitmq-template project more useful as a production tool for AsyncAPI developers in a .NET environment.

Motivation

As a heavy user of OpenAPI and NSwag, I believe this feature will provide a significant benefit to the project's productivity and flexibility for AsyncAPI developers. The ability to customize namespaces, data structures, and output file structure to fit specific needs will make the project more useful and applicable to a broader range of users.

This issue defines a list of tasks that need to be performed in this repo to make sure it's ci/cd automation works long term without any issues.

It is up to maintainers to decide if it must be addressed in one or multiple PRs.

Below are 3 different sections describing 3 different important ci/cd changes.

IMPORTANT-START
For GitHub workflows that contain This workflow is centrally managed in https://github.com/asyncapi/.github/ you do not have to perform any work. These workflows were already updated through the update in .github. The only exception is the workflows related to nodejs release. More details in Upgrade Release pipeline - in case of nodejs projects section
IMPORTANT-END

Deprecation of way data is shared between steps

Every single GitHub Action workflow that has echo "::set-output name={name}::{value}" need to be updated to follow echo "{name}={value}" >> $GITHUB_OUTPUT

We do not yet know when set-output will stop working. Previous disable date was 31.05 but now then say community needs more time.

For more details read official article from GitHub

Deprecation of node12

2nd bullet point is still relevant for you even if your projects in not nodejs project

• Every single workflow that uses setup-node action needs an update to follow v3 version of this action, and make sure minimum node 14 is used
• Now this part is more complex. Problem with node12 is that node-based GitHub Actions were using it in majority as a runtime environment. Look for example at this action.yaml file for setup-node action v2. So the job that you have to do is go through all the workflows, and verify every single action that you use, make sure you are using the latest version that is not based on node12. I already did review a lot of actions as part of this PR so maybe you will find some actions there and can copy from me. For example action/checkout needs to be updated to v3.

Node12 end of support in action is probably September 27th.

For more details read official article from GitHub

Upgrade Release pipeline - in case of nodejs projects

ignore this section if your project is not nodejs project

You have 2 options. You can:

A. choose to switch to new release pipeline using instruction from asyncapi/.github#205

B. stay with old release pipeline, and manually update GitHub workflows and actions used in it, you can inspire a lot from this PR asyncapi/.github#226

I definitely recommend going with A

Workflows related to release:

• .github/workflows/if-nodejs-release.yml
• .github/workflows/if-nodejs-version-bump.yml
• .github/workflows/bump.yml