6

I have often seen automated build processes, including Continuous Integration builds, commit changes made to source files during the build back into the version control repository that the source originated from*. Auto-incrementing version numbers is a common scenario where this is done but there are others.

My intuition is that this is a bad idea as it can litter the repository history with build-related commits and the build process needs to prevent accidentally re-triggering itself. However I don't have any concrete evidence that committing changes during a build is best avoided.

Can anyone cite references discussing the pros and cons of commit changes to version control during an automated build?

*Committing changes to a separate artifact repository is perfectly acceptable.

Jason Stangroome
  • 4,459
  • 3
  • 33
  • 39

1 Answers1

1

Auto-incrementing version numbers

That is a metadata, and putting metadata in (versioned) data is "evil": for the pros and cons, see this answer.

Continuous Integration includes the build automation, which is about being able to reproduce a build from a fixed set of versioned data.
If you change anything back in that same set, you sort of defeat its purpose.

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • I considered the issue of being able to reproduce a build but if a build run against Version N commits a change back to source control and creates Version N+1 then repeating the build against Version N again will be ignorant of N+1 and shouldn't change the output. – Jason Stangroome Dec 13 '11 at 06:16
  • @JasonStangroome: but it will create uselessly version N+1 over and over again. Just don't do it. It serves no useful purpose. CI is about *reading and building, no writing anything. – VonC Dec 13 '11 at 06:31