The linter CI job is currently broken in the actively maintained release-0.47 branch. The PR attempts to get it running again by decreasing its memory footprint. For a detailed analysis and the techniques used in this PR, please see #1194, and for a follow-up discussion, please see #1211.
I've reduced the concurrency of both phases to 1, increased the job's timeout to 90m and configured a more aggresive garbage collector by setting the GOGC to 50 for the release-0.47 branch after a series of experiments, where the parameters we used for the main branch did not perform well. At some point, we may also need to deploy these more aggressive parameters to the main branch as there should, currently, not be meaningful difference between the memory requirements of the linter runner between branches main & release-0.47, assuming we have not missed to backport any related change from the main branch. But the linter runner's peak memory consumption is currently on the edge but I suspect this could be a quality-of-service issue with the available hosted runners.
Description of your changes
The linter CI job is currently broken in the actively maintained
release-0.47
branch. The PR attempts to get it running again by decreasing its memory footprint. For a detailed analysis and the techniques used in this PR, please see #1194, and for a follow-up discussion, please see #1211.I've reduced the concurrency of both phases to 1, increased the job's timeout to 90m and configured a more aggresive garbage collector by setting the
GOGC
to 50 for therelease-0.47
branch after a series of experiments, where the parameters we used for themain
branch did not perform well. At some point, we may also need to deploy these more aggressive parameters to themain
branch as there should, currently, not be meaningful difference between the memory requirements of the linter runner between branchesmain
&release-0.47
, assuming we have not missed to backport any related change from themain
branch. But the linter runner's peak memory consumption is currently on the edge but I suspect this could be a quality-of-service issue with the available hosted runners.I have:
make reviewable
to ensure this PR is ready for review.backport release-x.y
labels to auto-backport this PR if necessary.How has this code been tested
Changes proposed here have been tested on a cold-cache here.