Add buildDiscarder and timestamp option to Jenkins

[BrennanGit]

This PR introduces a method for automatically deleting Jenkins builds after a certain time/number. This is needed so that Jenkins disk does not forever grow.

Currently this repo is using 133GB of space on the Jenkins master and now archiving 2.3GB every build! Reducing this would not only stop me needing to respec the jenkins master but should also make it run faster.

Please understand that THIS IS A DESTRUCTIVE CHANGE and once merged to develop will permanently delete old builds so please come forward with any concerns over the settings chosen if you have any.

We will use the buildDiscarder Jenkinsfile option to configure this on a repo-by-repo basis.

This process has been tested using this repo and this jenkins job.

Discussions about adding it to a previous repo are here: https://github.com/xmos/lib_aec/pull/448

---

Here is a link to the confluence page going into more detail about justification and usage.

The short version is we propose to delete any build older than 100 on the develop branch of this repo.

Please comment if you think this is unsuitable.

---

PS I have also opted to use this opportunity to add the timestamps option to jobs that do not already employ it. This makes it easier to diagnose any future Jenkins issues.

[BrennanGit]

The number here is the last 100 builds (matching the other times this change has been added) but in this case, that is unlikely to reduce the current space used by much. Can I then ask if we can set it to a lower number, say 50? Also I might suggest wrapping the archiveArtifacts of the wavs in some sort of when block so they are only archived when necessary.

[danielpieczko]

Also I might suggest wrapping the archiveArtifacts of the wavs in some sort of when block so they are only archived when necessary.

I would agree with that: it seems unnecessary to store all the output wav files from every run. But I haven't worked in this repo for a while, so I'll defer to others who are more familiar with the tests nowadays.

[mbanth]

Can I then ask if we can set it to a lower number, say 50?

50 runs is fine with me.

[mbanth]

Also I might suggest wrapping the archiveArtifacts of the wavs in some sort of when block so they are only archived when necessary.

Two instances of the same WAV file will, almost certainly, not be identical (across two runs). I do not know of a good criterion to use to determine when archiving is or is not necessary. If someone can suggest a good criterion, I'm open to the idea of using a when block. Otherwise, I think we have to live with using the space because we cannot know now what we may need to investigate in future.

[BrennanGit]

Are we ok to merge this once the build has passed? @shuchitak @mbanth

[mbanth]

Are we ok to merge this once the build has passed? @shuchitak @mbanth

Merging after a successful build is fine with me.

[shuchitak]

Are we ok to merge this once the build has passed? @shuchitak @mbanth

Yes, I'm okay with merging this.