fix: patching limits on local checks file

[simojo]

This PR patches the limits on the local check file such that they will not pose an obstacle for us in getting our build to pass. It does not change any functionality other than increasing the max value of counts for each check to 300.

[boulais01]

Hey @simojo, it looks like the checks are still failing on this PR. Is that the expected outcome?

[simojo]

@boulais01 yes, there are two separate issues causing our build to fail. They're both in separate PRs. See PR #87

[boulais01]

@laurennevill @jnormile @AidanNeeson @tuduun @gkapfham Can we get a look at this and the linked PR(#87 )?

[jnormile]

Could @gkapfham speak to the use of the current maximum numbers? I'd ask as to the intent behind using those specific values before just papering over them with new maximum values.

[AidanNeeson]

This will definitely help to fix the build. Having at least one maximum is important though because we still want to check something so this stuff does something to ensure the program is working correctly. That said, the more we add, we might run into this issue again, so maybe look into ways to future proof this if possible, or at least make a note when chasten is ready to be shipped to add the maximums back in for testing purposes.

[jnormile]

@AidanNeeson Were you listening in on our conversation? That's almost exactly what @gkapfham said. 😆

[CalebKendra]

@simojo made a feature that allowed us to fix this at #68

[AidanNeeson]

@AidanNeeson Were you listening in on our conversation? That's almost exactly what @gkapfham said. 😆

I had to make sure I documented his valuable insights for everyone to see! 🤣

[simojo]

Hi @AidanNeeson @jnormile @gkapfham, I believe this is addressed here. Please take time to look this fix over before discussing any further.

[laurennevill]

@gkapfham, to my understanding, this PR would not be necessary if PR #69 is merged successfully. @simojo can comment more on this if I am not correct.

For now, it is not on the priority list.

[simojo]

@gkapfham, to my understanding, this PR would not be necessary if PR #69 is merged successfully. @simojo can comment more on this if I am not correct.

For now, it is not on the priority list.

Yes, we can close this for that reason.