Repository navigation
Adopt and/or adapt Spectral rules from AsyncAPI v2 Core ruleset to v3 #1016
Description
Activity
- changed the title
[-]Spectral rules for AsyncAPI Spec v3[/-][+]Adopt/Adapt Spectral rules from AsyncAPI v2 to v3[/+]on Jun 13, 2024 - changed the title
[-]Adopt/Adapt Spectral rules from AsyncAPI v2 to v3[/-][+]Adopt/Adapt Spectral rules from AsyncAPI v2 Core rules to v3[/+]on Jun 13, 2024 - changed the title
[-]Adopt/Adapt Spectral rules from AsyncAPI v2 Core rules to v3[/-][+]Adopt/Adapt Spectral rules from AsyncAPI v2 Core ruleset to v3[/+]on Jun 13, 2024 bounty/candidate
- changed the title
[-]Adopt/Adapt Spectral rules from AsyncAPI v2 Core ruleset to v3[/-][+]Adopt and/or adapt Spectral rules from AsyncAPI v2 Core ruleset to v3[/+]on Jun 14, 2024 Bounty Issue's service comment
Text labels:
bounty/2024-Q3,bounty/medium,bounty/coding,bounty/unpicked,bounty/eol
First assignment to third-party contributors: 2024-06-21 00:00:00 UTC+12:00
End Of Life after: 2024-07-31 23:59:59 UTC-12:00@asyncapi/bounty_team
The Bounty Program is not a Mentorship Program. The accepted level of Bounty Program Participants is Middle/Senior.
Third-party contributors should coherently articulate how they are going to approach the resolution process when expressing a desire to work on this Bounty Issue.
-
For rule
asyncapi server variablesit will be mostly mostly similar toasyncapi2-server-variablesexcept in the input schema in place ofurlthere should behostandpathnamewith type string, and in the variables, inparsedUrlVariablespasshost+pathname. -
asyncapi3-channel-no-query-nor-fragmentit will be similar to asyncapi2-channel-no-query-nor-fragment -
asyncapi3-channel-parametersit is mostly done in my PR(fix: parser will throw an error when address is null/no param but param is present #1011 ), though i need to add the rules and its corresponding function in v3 -
asyncapi3-channel-serversfor this we need to create a function that will retrieve the keys (names) of the servers defined in theserversobject, then we need to Iterate over each channel in the channels object, and if the server name is not defined push the error
msg to the result array
cc @smoya (here is a brief outline of the first four rule)
-
@ibishal I read your DM's where you share what your contributions to AsyncAPI are, and I determined that this task requires a bit more of experience with not only the Parser but within the spec.
Not really sure you are the right candidate for this to work as a bounty issue, but feel free to submit PR's if you want to still work on it outside the bounty.
Happy to discuss if you truly believe I'm making a mistake here.If @ibishal wants to contribute, they can submit PRs for OTHER ISSUES, leaving the Bounty Issue intact, in order not to pollute its pristineness.
Reiterating what I mentioned to @ibishal here, any user is encouraged to work on any of the issues available, no matters if they belong to an unassigned Bounty. That doesn't mean those issues will be assigned ever to the user since we only assign issues in programs such as Bounty, GSoC, etc.
Once a Bounty issue is assigned, any other PR sent in parallel regarding that issue will be discarded but only if that Bounty issue is assigned. If the issue is not assigned yet, why would I stop someone from contributing to it?At least this is how I see it as maintainer of this repo.
cc @jonaslagoni @magicmatatjahu just in case they wanna share their opinion on this
If a regular contributor made a PR addressing
10/100of aMediumBounty Issue, this already erodes the initial Complexity Level of the Bounty Issue with which it was submitted and accepted into the Bounty Program. Not talking about20/100or even50/100.So, to avoid the impact of this period between the assignment of the GitHub label
bountyand the assignment of the Bounty Issue to a Bounty Program Participant ofthree (3) days, I would propose to stop accepting PRs starting from the moment of assignment of the GitHub labelbounty(which I intentionally made unambiguous, dependent on the unchangeable GitHub timestamp) and not starting from the moment of the assignment of the Bounty Issue to a Bounty Program Participant.The idea behind the Bounty Program is that there is one Bounty Program Participant and one AsyncAPI Maintainer, so it's clearly understandable who solved the Bounty Issue and therefore who should be rewarded for it.
cc @derberg
In other words, acceptance of PRs between the moment of assignment of the GitHub label
bountyand the moment of assignment of the Bounty Issue to a Bounty Program Participant creates a race condition for the Bounty Program, which I obviously try to avoid by shifting mutex earlier in the execution sequence.In other words, acceptance of PRs between the moment of assignment of the GitHub label
bountyand the moment of assignment of the Bounty Issue to a Bounty Program Participant creates a race condition for the Bounty Program, which I obviously try to avoid by shifting mutex earlier in the execution sequence.As shared via DM with you @aeworxet, I believe this topic deserves a proper discussion, and in another place rather than this issue. I'm happy to contribute to that discussion and express my concerns. I think this discussion should involve maintainers of other repos as well.
This Bounty Issue was not picked up for resolution by any Bounty Program Participant before the End Of Life, so it has been removed from the Bounty Program calendar quarter round
2024-Q3.This issue has been automatically marked as stale because it has not had recent activity 😴
It will be closed in 120 days if no further activity occurs. To unstale this issue, add a comment with a detailed explanation.
There can be many reasons why some specific issue has no activity. The most probable cause is lack of time, not lack of interest. AsyncAPI Initiative is a Linux Foundation project not owned by a single for-profit company. It is a community-driven initiative ruled under open governance model.
Let us figure out together how to push this issue forward. Connect with us through one of many communication channels we established here.
Thank you for your patience ❤️
Context
Spectral rules are the rules that validate AsyncAPI documents. There are different types or levels:
In the case of AsyncAPI Spec v3, the rules that apply ATM are:
asyncapi-is-asyncapi- The input must be a document with a supported version of AsyncAPI.asyncapi-latest-version- Checking if the AsyncAPI document is using the latest version.asyncapi-document-resolved- Checking if the AsyncAPI document has valid resolved structure.asyncapi-document-unresolved- Checking if the AsyncAPI document has valid unresolved structure.asyncapi-internal- That rule is internal to extend Spectral functionality for Parser purposes.asyncapi3-operation-messages-from-referred-channel- Operation "messages" must be a subset of the messages defined in the channel referenced in this operation.asyncapi3-required-operation-channel-unambiguity- The "channel" field of an operation under the root "operations" object must always reference a channel under the root "channels" object.asyncapi3-required-channel-servers-unambiguity- The "servers" field of a channel under the root "channels" object must always reference a subset of the servers under the root "servers" object.Description
If you check how many specific v2 rules are, you will notice a lot compared to v3. This PR tries to fix that gap between Spec versions and adopt or adapt those rules from v2 that make sense in v3. We will be focusing on Core rules and skip Recommended rules by now (we will work on it in a next iteration).
Core Rules we might want to adopt/adapt from v2 to v3:
asyncapi3-server-variablesfor the v3 core ruleset #1017asyncapi3-channel-no-query-nor-fragmentfor the v3 core ruleset #1018asyncapi3-channel-parametersfor the v3 core ruleset #1019asyncapi3-channel-serversfor the v3 core ruleset #1020asyncapi3-operation-operationId-uniquenessfor the v3 core ruleset #1021asyncapi3-message-messageId-uniquenessfor the v3 core ruleset #1022asyncapi3-tags-uniquenessfor the v3 core ruleset #1023asyncapi3-message-examplesfor the v3 core ruleset #1024Discarded rules:
asyncapi2-server-security- Server have to reference a defined security schemes.securityfield.asyncapi2-operation-security- Operation have to reference a defined security schemes.asyncapi2-server-security