Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

OpenAPI clients code generation - Kiota #87

Closed
andreaTP opened this issue Jan 26, 2023 · 12 comments
Closed

OpenAPI clients code generation - Kiota #87

andreaTP opened this issue Jan 26, 2023 · 12 comments
Assignees

Comments

@andreaTP
Copy link
Contributor

andreaTP commented Jan 26, 2023

Reference the Original doc.

@andreaTP
Copy link
Contributor Author

cc. @tombentley please assign this issue to me.

@tombentley
Copy link
Contributor

@andreaTP it's an AP you want, right? (not an ADR)

@andreaTP
Copy link
Contributor Author

Hi @tombentley , thanks for taking a look!

I'm finding it a little confusing to identify if I should submit an AP or an ADR.

Currently in the available documentation: https://github.com/bf2fc6cc711aee1a0c2a/architecture/blob/main/pages/about/index.adoc#architectural-pattern

I can see that, in the AP description, the term ADR is used interchangeably and I'm finding it hard to identify the key differences. Would you mind clarifying or directly suggesting the best curse of action?

@tombentley
Copy link
Contributor

ADR records a decision (specific to a single service) that MUST be followed in applicable circumstances. The only way to avoid it is to supersede the decision.

PADR records a decision (applying to all services) that MUST be followed in applicable circumstances. The only way to avoid it is to supersede the decision.

Obviously these are a bit written-in-stone. So AP provides mechanism for saying "We think this is what we want to do, but we want to see whether the pattern is really generally applicable before we promote it to PADR".

From the draft document you linked, I think this should be an AP. Once we've got experience with Kiota for at least one service we could have an PADR to record that it's what everyone MUST use from now on.

Does that sound OK/work for you?

@andreaTP
Copy link
Contributor Author

Thanks a ton for the clarification.

Yes, I'm fine with submitting it as an AP!

@tombentley
Copy link
Contributor

create ap

@tombentley
Copy link
Contributor

/create ap

bf2-arch-bot bot added a commit that referenced this issue Jan 30, 2023
@bf2-arch-bot
Copy link
Contributor

bf2-arch-bot bot commented Jan 30, 2023

Closing following creation of AP-17
@andreaTP, please write your content in _ap/17/index.adoc and open a PR for AP acceptance.

@bf2-arch-bot bf2-arch-bot bot closed this as completed in 51589e6 Jan 30, 2023
@bf2-arch-bot bf2-arch-bot bot closed this as completed Jan 30, 2023
@andreaTP
Copy link
Contributor Author

@tombentley the number given by the automation is colliding on @shawkins #82

@tombentley
Copy link
Contributor

Sigh. Avoiding this kind of thing is why the automation allocates the id in an initial (basically empty) PR. It's not the fault of @shawkins for not knowing that (because the bot is only now working thanks to @grdryn).

@andreaTP I'll bump your AP id manually. That should be enough to fix it for future APs too.

@tombentley
Copy link
Contributor

@andreaTP you now have ADR 18 (you can re-fetch main).

@andreaTP
Copy link
Contributor Author

Cool, thanks for sorting things out! I'll continue to work on AP 18

grdryn added a commit to grdryn/arch-bot that referenced this issue Feb 1, 2023
The `repo.getHomepage()` returns the website configured in the
repository details, so you can see the link behind the .adoc file path
in
bf2fc6cc711aee1a0c2a/architecture#87 (comment)
points to that site rather than to the corresponding file page on
GitHub.

It seems like `repo.getHtmlUrl()` is the best choice.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants