Explicitly save cache in primer jobs

[jacobtylerwalls]

On the theory that we might see primer indeterminacy due to incompletely created virtual environments being cached when jobs are interrupted (due to cancel-in-progress: true), exercise some control by running separate actions/restore and actions/save actions.

Refs #9925 (comment)

cc/ @akamat10

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 95.80%. Comparing base (67acc96) to head (46a37ed).
Report is 1 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #9932   +/-   ##
=======================================
  Coverage   95.80%   95.80%           
=======================================
  Files         174      174           
  Lines       18933    18933           
=======================================
  Hits        18139    18139           
  Misses        794      794           

[akamat10]

I have one more theory on where I think another set of errors might be coming from. The Django import errors in sentry might tied to the order in which the projects are processed (the projects are in a dictionary so the order may be different every time) and we are somehow not clearing the cache from running the other previous projects. So if the Django project processed first, you may not see the Django import errors in sentry. I haven't been able to pinpoint why the cache clearing isn't working but will need some time to pinpoint where the problem is. Perhaps you have an idea.

[jacobtylerwalls]

@akamat10 What concerns me about the django <--> sentry interaction is that I'm wondering why the django imports are being picked up at all. We're not installing dependencies of primer projects (to my knowledge). Maybe we should. But since we're not intending to, are we sometimes picking up django as a namespace just because Django doesn't use a src/ folder? Why only sometimes?

[akamat10]

My theory was that it depends on linting order of projects without any django installation. I have to verify if the order somehow varies from one run to the next. But one theory I need is to check is whether previous project modules are getting cached or whether their directories are becoming part of search path discovery and getting used in linting of subsequent projects. So in that scenario say djanjo project linting happened first. Either astroid has now cached django modules or django modules in search discovery path. If that were to happen, pylint knows about django, and when sentry linting happens, there is no import or no-member error. Just a theory at this point and I need to check if something like that is happening. I do see primer passing the option to clear cache flag here so it shouldn't be happening. But who knows what could be going on.

[akamat10]

Ok I have confirmed it is related to django repo running in the same batch as sentry. Turns out both PR run and main run give no-name-in-module error but the error is slightly different.
PR run error:

            {   
                "type": "error",
                "module": "sentry.event_manager",
                "obj": "",
                "line": 19,
                "column": 0,
                "endLine": 19,
                "endColumn": 43,
                "path": "tests/.pylint_primer_tests/getsentry/sentry/src/sentry/event_manager.py",
                "symbol": "no-name-in-module",
                "message": "No name 'encoding' in module 'django.utils'",
                "message-id": "E0611"
            }

main run error:

            {   
                "type": "error",
                "module": "sentry.event_manager",
                "obj": "",
                "line": 19,
                "column": 0,
                "endLine": 19,
                "endColumn": 43,
                "path": "tests/.pylint_primer_tests/getsentry/sentry/src/sentry/event_manager.py",
                "symbol": "no-name-in-module",
                "message": "No name 'utils' in module 'django'",
                "message-id": "E0611"
            },

I don't know why they give different messages but they both shouldn't exist if the cache from django linting was cleared correct. That is because the variables checker code here will return if import of the django module fails and will skip checking for no-name-in-module. It turns out this is a bug with clearing the astroid cache at the end of each repo run. We need to clear out _mod_file_cache in AstroidManager.clear_cache(). I have locally tried it and confirmed that clearing the above cache makes the no-module-in-name error go away. I will send a PR over the weekend.