docs: disable unnecessary link

[honzajavorek]

Supersedes #896:

• better commit names
• made on top of current master, properly using git and not a GitHub pencil 😅
• using inline code per @B4nan's comment docs: fix markdown to disable an unnecessary link #896 (review)

[honzajavorek]

Still failing with

[INFO] [en] Creating an optimized production build...
Error:  Unable to build website for locale en.
Error:  Error: You specified the `smartlook` object in `themeConfig` but the `projectKey` field was missing. Please ensure this is not a mistake.

[B4nan]

Hmm I think I know whats happening, my fix only handles not set env var, but maybe we are getting empty string in there instead.

This should help I think 24ce0fb

[B4nan]

yeah good, that was it.

btw one unrelated note, it does not matter much in this repository, but generally speaking, commits that don't change the library itself shouldn't be marked as fix/feat, those should be reserved for actual library fixes/features, things that belong to changelog (we generate changelogs based on the git history).

as said, it does not matter much here, as this is not a library repository, but it does matter for all the other projects like SDKs or clients, where commits like this should be marked as ci: or docs: or chore:. since this changes docs content only, i would go with docs:

[B4nan]

also fixed the broken langchain link here 53bc0c6

[B4nan]

hmm and here is the last broken link, not sure why lychee didn't print both :/

f1d0234

[B4nan]

ok, finally a green light :D next time it should be simpler, be sure to update your fork. also sent you an invite to the project contributors so you can just create a branch instead of using a fork.

[honzajavorek]

Thanks for resolving the issue and for merging the PR! And for the invite.

btw one unrelated note, it does not matter much in this repository, but generally speaking, commits that don't change the library itself shouldn't be marked as fix/feat, those should be reserved for actual library fixes/features, things that belong to changelog (we generate changelogs based on the git history).

as said, it does not matter much here, as this is not a library repository, but it does matter for all the other projects like SDKs or clients, where commits like this should be marked as ci: or docs: or chore:. since this changes docs content only, i would go with docs:

I use the prefixes in the context of a product at hand. E.g., if adding commits to apify/apify-sdk-python, the main product is a Python library, so fix in code would be fix, and updates to documentation would be docs. In the context of apify/apify-docs I felt like the main product of the repo is the docs, the text files, and most of the commits will be referring to changes in the docs, so I've used fix etc. accordingly. In the context of documentation site, changes to code feel more like chore to me.

Looking at the commit history, it seems like @TC-MO sticks to marking everything as docs, the same way you suggest, but @metalwarrior665 seems to do the same mental shift as me, e.g. 74bee05 or 3e21f78 I don't mind which it is, just wanted to provide my reasoning on why I did it. I will follow whatever convention you sirs agree upon.

[B4nan]

I use the prefixes in the context of a product at hand. E.g., if adding commits to apify/apify-sdk-python, the main product is a Python library, so fix in code would be fix, and updates to documentation would be docs. In the context of apify/apify-docs I felt like the main product of the repo is the docs, the text files, and most of the commits will be referring to changes in the docs, so I've used fix etc. accordingly. In the context of documentation site, changes to code feel more like chore to me.

True, anyway, it's not very important since there is no generated changelog, which is the main reason to adhere to those rules, feel free to do it this way here.