Static analysis config and convenience scripts in source control

Question

1) Should static analysis tool config be placed in source control? This config is not needed to compile/run software and some developers can have different preferences (even within coding convention). On the other hand placing such config in source control and declaring static analysis tool as "official part of project" can encourage everybody to test his code and help keep it very consistent. This question is mostly about open source because in commercial projects you will establish strict workflow anyway.

2) Should convenience scripts (generating documentation, running analysis, running tests, deploying, generating installer) be placed in source control? Theses scripts have to be cross-platform and may not work well on every system. People may just use IDE to accomplish some of these tasks. But requiring everybody to write his own boilerplate seems somewhat stupid to me. This question is mostly about interpreted languages because when working with compiled languages this is usually achieved using build tool which is not needed to build program in dynamic languages.

Answer 1

I understand your hesitation.

Even though those scripts are useful they are not part of the build process, and as such are not necessary, per se.

However I am on the opinion that any configuration file / specifically tailored script that runs on the code should be in the source control repository.

Why ?

Because if I check out an old version, and the new scripts does not work on it, how am I supposed to run the static analysis ? How am I supposed to update the documentation ?

Anything that interacts directly with the code should be embedded in the code package ... or referenced.

If you wish to maintain the scripts outside of the source control, for example because they're quite big and impact the checkout/update time, it's fine too, however you'll need to properly deliver them (versioned) and have a file tucked with the code that describe which version of the script/tool should be used (works).

Generally, configuration files are never big enough to warrant being delivered (and versioned) separately, from my experience.

Answer 2

There is a better reason to check in ALL supporting configs and scripts.

Builds should be reproducible. I should be able to go back to the source as it was 3 months ago and be able to produce the same build (except for date stamps) as the one that was produced 3 months ago. This ability to reproduce with a minimal delta allows for stronger assertions and better confidence when doing things like fixing bugs.

Answer 3

The theory is that anything used in the production of a build should be under source control. The intent being that you should be able to replicate the entire construction and build process out of the repository. It is possible to take this as far as putting your development tools into the repository but that's a little excessive in my opinion.

For you this means that not just the code, but everything else aswell, be it build scripts, test scripts or configuration. So yes, your static analysis configuration and convenience script goes in the repository.