feat: add new custom resolver to fetch the reference from private repo

[AayushSaini101]

Resolves: #1796

• Create a custom resolver to fetch the reference from the private repo
• Add new command auth add for storing the repo name and repo token.
• Tests and documents need to be updated

[changeset-bot]

🦋 Changeset detected

Latest commit: da60cf0

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@asyncapi/cli	Minor

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[github-actions]

Changeset has been generated for this PR as part of auto-changeset workflow.

Please review the changeset before merging the PR.

---
'@asyncapi/cli': minor
---

feat: add new custom resolver to fetch the reference from private repo

- 88ceb3d:  add new custom resolver to fetch the reference from private repo
- 4974358: Update src/domains/services/validation.service.ts

Co-authored-by: Fran Méndez <fmvilas@gmail.com>
- c764ee6: update instruction in the test case for the validation success
- 2b9457f: fix test-cases
- 86bbfc4: fix lint issue across the project
- 6813ef0: Update 1875.md

If you are a maintainer or the author of the PR, you can change the changeset by clicking here

Tip

If you don't want auto-changeset to run on this PR, you can add the label skip-changeset to the PR or remove the changeset and change PR title to something other than fix: or feat:.

[AayushSaini101]

@fmvilas success is true defines the command is successfully executed

[fmvilas]

The validation succeeds but the document is invalid

This is tricky, isn't it? How would you justify this decision to another developer whenever they get result.success ==== true but the document is invalid? If that's the case, we can't rely on result.success to see if the document is valid or not.

Also, think about it, "validation succeeds" but it's "invalid" (i.e., not valid). Isn't it a contradiction?

[AayushSaini101]

@fmvilas, actually, the success is defined complete execution of the command; it is independent of whether the document is valid or not.

If the document is invalid in, we can see a status field that shows data: { status: invalid}, we can check in the following the pic : )

I have added a comment on the test cases to avoid confusion : )

[fmvilas]

Please next time don't force-push 🙏 It completely removes the whole history and makes it harder to review.

[fmvilas]

The validation succeeds but the document is invalid

This is tricky, isn't it? How would you justify this decision to another developer whenever they get result.success ==== true but the document is invalid? If that's the case, we can't rely on result.success to see if the document is valid or not.

Also, think about it, "validation succeeds" but it's "invalid" (i.e., not valid). Isn't it a contradiction?

[aeworxet]

@asyncapi/bounty_team

[Shurtu-gal]

@fmvilas

Also, think about it, "validation succeeds" but it's "invalid" (i.e., not valid). Isn't it a contradiction?

So, how all services currently work, is if there is a uncaught or unresolveable error it returns an error response. The success basically means that the service ran properly. Inside the data the status of the document is shown if its valid | invalid.

This can be changed though if you have some suggestions.

You can see it here:
https://github.com/asyncapi/cli/blob/master/src/domains/services/base.service.ts#L1-L25

[AayushSaini101]

/u

[AayushSaini101]

/u

[fmvilas]

@fmvilas

Also, think about it, "validation succeeds" but it's "invalid" (i.e., not valid). Isn't it a contradiction?

So, how all services currently work, is if there is a uncaught or unresolveable error it returns an error response. The success basically means that the service ran properly. Inside the data the status of the document is shown if its valid | invalid.

This can be changed though if you have some suggestions.

You can see it here: https://github.com/asyncapi/cli/blob/master/src/domains/services/base.service.ts#L1-L25

I see it's not an issue of this PR but it's definitely weird, don't you think so? Think about the devs than don't know the code base and are only using the CLI.

[fmvilas]

Let's get this merged 🙂

cc @asyncapi/bounty_team

[AayushSaini101]

/u

[sonarqubecloud]

Quality Gate passed

Issues
14 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[Shurtu-gal]

I see it's not an issue of this PR but it's definitely weird, don't you think so? Think about the devs than don't know the code base and are only using the CLI.

• Agree with the weirdness part, any suggestions on how it could be improved.
• Regarding the devs statment, this success or failure is not shown to CLI users. If the doc is invalid it just shows the doc is invalid. The service output is irrelevant here I suppose?

[AayushSaini101]

/rtm

[fmvilas]

Yeah, if CLI users are not suffering it, that's fine. However, I think it's a fine line. If you're not aware of this difference, it's easy to push wrong code in the future.

As per how to fix it, I'd just make it fail. If something doesn't resolve, trigger the error. A call to a method called validate() should return success: true if, and only if, the document is valid. If a reference is not resolved, then the document isn't valid, right? Or, at the very least, we couldn't finish the validation. This reminds me of people responding with 200 OK and { "error": "..." } in HTTP APIs. If there's an error, is not OK, so don't use the 200 code. Same here.

The above is if you want to preserve the current API. I'd go one step beyond and simply remove the success field altogether. If the call to validate() doesn't throw an error, it means it's valid. Otherwise, you can catch the error(s).