ci: add Jenkinsfile, requirements.txt and redirect

[jakubgs]

This adds CI builds for both main branches:

• develop built by CI job to publish to https://dev-help.status.im/
• master built by CI job to publish to https://help.status.im/

Changes should be made against develop and then once ready master should be rebased on develop to push the changes to the main site.

Related: https://github.com/status-im/infra-misc/commit/305f9445
Resolves: #27

[jorge-campo]

I'm afraid I can't make all the links work on the Status Help site build. The links only work at the / level on the main index.html file https://github.com/status-im/help.status.im/blob/develop/docs/en/index.md.

• The "Getting started section" (for example) shows the proper URL https://dev-help.status.im/en/getting-started/
• Other docs like "Download Status for Mac" show the wrong URL https://dev-help.status.im/help.status.im/getting-started/download-status-for-mac

I'm not controlling the URLs from within Material config at mkdocs.yml.

Note: GitHub Pages is still enabled on this repo, and I think it shouldn't be if we go with our own CI. I have removed them in other repos by setting the config to "none," according to GitHub's help.

[jakubgs]

@jorge-campo that has nothing to do with method of deployment and everything to do with the contents of the documents.

Look at this file:

help.status.im/docs/en/getting-started/index.md

Lines 14 to 15 in 3124084

	- [Download Status for **Mac**][download-status-for-mac]
	- [Download Status for **Linux**][download-status-for-linux]

Do you see anything wrong here? Or this one:

help.status.im/docs/en/getting-started/download-status-for-mac.md

Line 14 in 3124084

1. Visit [status.im/get :octicons-tab-external-16:][status-web-download]{:target="_blank"}

Please look at the format of links in Markdown:

• https://www.markdownguide.org/basic-syntax/#links
• https://www.mkdocs.org/user-guide/writing-your-docs/#linking-to-pages

[jorge-campo]

Hey @jakubgs, I'll add here the information we discussed, for the record.

We don't use Markdown URLs in the traditional Markdown way: [My link](https://path-to-my-link). Instead, we use a sort-of includes file that exists at the end of every Markdown document:

--8<-- "includes/urls-en.txt"

the urls-en.txt file stores the URL information for all links in the English language; this is a snippet of this text file:

[download-status-for-linux]: /help.status.im/getting-started/download-status-for-linux
[download-status-for-mac]: /help.status.im/getting-started/download-status-for-mac
[run-status-app-first-time]: /help.status.im/getting-started/run-status-app-first-time

Why are we doing this? Two main reasons:

• URLs depend on the document title and document path in the repo. These change from time to time, and tracking these changes across multiple languages is prone to error.
• URLs are hard for translators; they don't know if this is something that should or shouldn't be translated. This results in less-than-perfect translations that must be reviewed.

Managing URLs is hard, and there isn't a perfect solution. But I believe that by centralizing the URLs for each language on its own includes file, we can reduce the burden considerably.

Notice that this is supported by Material for MkDocs through the Snippets extension, and described in other installations. Notice also that this works as expected when I build the docs locally using mkdocs gh-deploy --force and when I use GitHub Pages. See here:

CleanShot.2022-04-21.at.10.57.22.mp4

This is the reason I think the build is somehow messing with this includes/urls-en.txt file, giving these long-and-weird URLs you mention in your message.

[jakubgs]

For future reference, the issue with the links was their definition. Before it was:

[download-status-for-linux]: /help.status.im/getting-started/download-status-for-linux
[download-status-for-mac]: /help.status.im/getting-started/download-status-for-mac
[run-status-app-first-time]: /help.status.im/getting-started/run-status-app-first-time

But the correct form is just the path without the domain or the weird prefix slash:

[download-status-for-linux]: /en/getting-started/download-status-for-linux
[download-status-for-mac]: /en/getting-started/download-status-for-mac
[run-status-app-first-time]: /en/getting-started/run-status-app-first-time

[jorge-campo]

Looks good to me, @jakubgs. Thanks for all the changes and the fixes to the edit_uri paths.