CODEWITHSUNDEEP
continuous-integration
Matthias
Matthias

Reputation: 16209

Build scripts for open source projects

My company is developing an open source project. Therefore we have to consider two different build script setups. The first is a local build and is used by us as well as by the community. The second build is performed on a CI server (we use team city).

Now two questions arise:

  1. Should we put the server specific build files in the same repository as the local build files?
  2. If yes, how do we handle sensible data like? For instance, the NuGet API key or the version information which is incremented with every nightly/weekly build?

Situation right now: we put only the local build files in the repository and keep the sensible stuff in a parent directory. Therefore it feels a bit clumsy (at least for me personally).

Sitation which I can think of: Have a local.build and server.build file in the repository. Then in team city set a system variable containing the passwords and version numbers. Right now I don't now how team city handles the visibility of the properties. Of course we don't want the password to be accessible or readable by every of our developers.

Upvotes: 1

Views: 134

Answers (1)

John Hoerr
John Hoerr

Reputation: 8025

I think that your intuition is good with the second option. You could include both scripts in source control and pass variables to server.build, or you could perhaps move the entire server.build process into a TeamCity build configuration.

Version numbers: TC handles version numbers with an incrementing build counter, to which you can prepend any arbitrary major.minor.etc. You can configure the format of the build number on the General Settings page, under Build Number Format. On our team we have a build parameter, %version%, which we fill in with the major.minor values. Our Build Number Format is then set to %version%.{0}, which gives us major.minor.build. This combined value is available via the %system.build.number% variable.

Sensitive Data: You can create build parameters that mask sensitive data. Add a new parameter and click the Edit button in the Spec field. You can then declare that the parameter should be treated as a password (among other options.) The parameter is then encrypted and obfuscated. You can use it the same way you would any other build parameter.

Upvotes: 1

Related Questions