Improve Github action workflows

[cdce8p]

Description

Improve multiple issues with our Github actions workflows.

• Remove restore-keys. Especially on Windows there are issues with reusing old cache entries and trying to install newer versions. Those are just skipped if the old one still satisfies the requirement. It's easy / fast enough to create a whole new environment if something changes.
• Log astroid and pylint versions to help with debugging if necessary.
• Reset cache versions.
• Add check-latest: true for setup-python action. This will prevent cache restore issue when runners use different Python patch versions. https://github.com/actions/setup-python/blob/main/docs/advanced-usage.md#check-latest-version
• Add KEY_PREFIX env variable to more easily identify the key prefix in each workflow.
• Replace setup.cfg with pyproject.toml for file hash
• Move comment-hider version in comment after sha. With the latest update, dependabot is now able to update it as well. That does not mean I would recommend replacing the version pins for the Github actions. https://github.blog/changelog/2022-10-31-dependabot-now-updates-comments-in-github-actions-workflows-referencing-action-versions/
• Add pins for the latest version of setup-node and github-script

Note
With these changes, it's only necessary to bump the primer cache versions when updating astroid.

[coveralls]

Pull Request Test Coverage Report for Build 3377667671

• 0 of 0 changed or added relevant lines in 0 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage remained the same at 95.381%

---

Totals
Change from base Build 3367355028:	0.0%
Covered Lines:	17241
Relevant Lines:	18076

---

💛 - Coveralls

[Pierre-Sassoulas]

Thank you, I'll be glad to not have to update the cache all the time 👌

[Pierre-Sassoulas]

Is that a forgotten debug statement or is this voluntary ?

[cdce8p]

It's a debug statement, but I think a useful one. It can help debug issues when updating astroid and simplify checking if the correct astroid version is used.

[Pierre-Sassoulas]

I'm wondering if we should fix the primer so they recreate the venv if they can't recover it from cache. This is really an annoying bug it's worth the use of CI imo. Unless there's a real problem with the cache that never work then we need to fix it elsewhere.

[cdce8p]

I'm wondering if we should fix the primer so they recreate the venv if they can't recover it from cache. This is really an annoying bug it's worth the use of CI imo. Unless there's a real problem with the cache that never work then we need to fix it elsewhere.

I haven't spend much time looking at it but as I understand it we want to restore a base run from main and if we don't have one to restore, it fails. Maybe @DanielNoord does know something more?

In any case, we can address this separately in another PR.

[cdce8p]

Thank you, I'll be glad to not have to update the cache all the time 👌

We still need to update the Primer cache manually, unfortunately. At least for now.

[DanielNoord]

Yeah I made the decision to have only main restore the venv because otherwise we need to add additional checks that the PR branch doesn't create a venv that is incompatible with the main venv.

[cdce8p]

Yeah I made the decision to have only main restore the venv because otherwise we need to add additional checks that the PR branch doesn't create a venv that is incompatible with the main venv.

With the cache access restrictions, any cache created from the PR branch can only be used for that PR. So it might actually be safe. Furthermore, the cache only includes the venv which isn't modified after the initial install.

I can prepare a PR to show what I had in mind.

https://docs.github.com/en/actions/using-workflows/caching-dependencies-to-speed-up-workflows#restrictions-for-accessing-a-cache