Autogenerate API docs

[NissesSenap]

Description

• Update makefile and auto run after test, this way they are always run by a developer
• Add to CI to check for dirty file-system
• Create documentation/api/ to store the new api docs.

Relevant issues/tickets

#519
#502

Type of change

• Documentation
• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)

Checklist

• This change requires a documentation update
• I have added tests that prove my fix is effective or that my feature works
• I have added a test case that will be used to verify my changes
• Verified independently on a cluster by reviewer

Verification steps

[NissesSenap]

The main question is if we like this kind of docs, unless you have a markdown previewer in your IDE it's more or less useless.
If we do not enjoy it I think we should start thinking of hosting a hugo page with the docs.
I haven't updated the current docs since I didn't come up with a good way to rewrite them. One way forward can of course be to keep both but that can also create confusion.

Since crdoc generates the data from the CRD it shows a few places where we should improve the comments in the .go files that generates the CRD:s.

The bad thing with crdoc is that it isn't possible to add comments in to it and that is something that other code generators can handle. But as I mentioned in the issue, the other ones don't generated markdown.

So yeah please come with feedback, if we don't like this solution lets try to come up with something else :)

[hubeadmin]

The main question is if we like this kind of docs, unless you have a markdown previewer in your IDE it's more or less useless.
If we do not enjoy it I think we should start thinking of hosting a hugo page with the docs.
I haven't updated the current docs since I didn't come up with a good way to rewrite them. One way forward can of course be to keep both but that can also create confusion.

Since crdoc generates the data from the CRD it shows a few places where we should improve the comments in the .go files that generates the CRD:s.

The bad thing with crdoc is that it isn't possible to add comments in to it and that is something that other code generators can handle. But as I mentioned in the issue, the other ones don't generated markdown.

So yeah please come with feedback, if we don't like this solution lets try to come up with something else :)

I like this solution, I think it's a much neater way of presenting the information that's already there, a lot of it is self-explanatory, but there are, as you pointed out, places where we need to improve our crd docs.
As for duplication, I think we should try and maintain the api doc as best as we can (by providing valuable description field values).
However, I don't think we need to remove too much from our current documentation. The way I see it is that an API reference is good and really valuable if you want to know what a field is used for and why it's there, but if you want a deeper understanding of the feature you're using, then that's when our "classic" documentation makes more sense, for a more "human-friendly" approach.

[hubeadmin]

Thanks @NissesSenap, I really like this change.

One small thing, can you hyperlink the API doc to the main README? let's make it more visible, it might be hard to find otherwise (let's not hide your contribution 😅 )

Looks good to me! Once you hyperlink, feel free to merge!