CI: organizing bootstraping

[Anton-Latukha]

Be free at merging #2444, I would rebase this to whatever needed.

---

Using the same bootstrapping process so workflows have the same setup & so can share the caches between them.

_{(A work derived from #2427)}

[Anton-Latukha]

On caching workflow: added the PR trigger, ran the successful build/test on caching workflow & removed the trigger. The result is in https://github.com/haskell/haskell-language-server/actions/runs/1549204625.

[jneira]

Thanks for reorganizing ci scripts, they will look great, only some minor comments

[Anton-Latukha]

[skip circleci]

Seems I encountered that in several forms.
Where is to find that information?

I found, https://circleci.com/docs/2.0/skip-build/ but that talks about [skip ci] & mentions to not work for the fork PRs.

[jneira]

[skip circleci]

Seems I encountered that in several forms. Where is to find that information?

I found, https://circleci.com/docs/2.0/skip-build/ but that talks about [skip ci] & mentions to not work for the fork PRs.

yeah and it only works in commit messages, I made up a hack to skip the build
see

haskell-language-server/.circleci/config.yml

Line 21 in ddacbce

- run:

[jneira]

Looks good, thanks for addressing comments

[jneira]

many thanks again, i hope my succesive cmments were not too burdensome

[Anton-Latukha]

Well, besides we could established minimization a bit earlier. I do not know how to properly establish that. I wanted to copy-paste the bootstrap code, I did not wanted to fit it to the workflows, so it would be the same & essentially sacked or cleaned-up afterward. & I also had an eyeball to preserve the same code to submit the next steps, & so some of them would be used & then look at & the clean-up. But that is probably too much of a stretch to multiple PRs.

I basically wanted to get 1 PR & split its code into 3 stages & merge them & then do clean-up. But as I said that is probably a stretch & submitting PRs which code has unused features & code that may be used in the future, that is: "4. Code with added features".

A kind & strong ask & encouragement to keep PRs to the code so they would be quickly mergable, & so to fit the code to the purpose so maintainer does not need to go over it, would've made me go over the whole codebase more thoroughly & submit all additional code that is not related to current code into next PRs where it would relate. Then & the law of triviality (Wadler's law) & the self-aware understanding of that looms over the process. It is well Ok here, because the main trap of "Wadler's law" is bogging the process documentation in rewording/discussion (since I loved to contribute docs in the past - I "got the experience" & the idea & only recently found the literate famous nicely put law). Several small details some put & some removed & the last note probably still would've happened nevertheless. It all also was heavily multiplied by numerous CI blockages & waiting times in the process, rebases.

What I want to take from this is to on splitting the PR I should treat each small PR as a one PR & code "in itself".