Nightly Builds Produces HUGE database and Thousands of SAMAP files

Our code management system produces nightly builds, instantaneous builds upon GIT PUSH to a central server, and weekend builds of all BRANCHES.  This has resulted in a quite large SQL database and 10's of thousands of SAMAP files in our storage share. 

What is the recommended workflow to avoid accumulating SmartAssembly CRUFT with intermediate builds which are not actually customer facing?
Tagged:

Answers

  • Alex BAlex B Posts: 1,131 Diamond 4
    Hi @LWSpencer42,

    You should be able to specify for SmartAssembly to obfuscate only on builds built on the Release configuration which may be one way to get around this (i.e. have your non-release builds build as debug and then set the actual release to build on the Release configuration and have SA only integrate on those builds.

    Is that something that might work for you?

    Kind regards,
    Alex
    Product Support Engineer | Redgate Software

    Have you visited our Help Center?
  • LWSpencer42LWSpencer42 Posts: 5 Bronze 1
    edited May 6, 2019 2:17PM
    That might work to a point, but it would not allow us to verify that our SmartAssembly configurations are valid with new software changes.  I was hoping for a command line parameter which would compile the SAPROJ for verification without storing anything into the database.

    Frankly, that sounds like it might be a pretty handy feature.
  • Alex BAlex B Posts: 1,131 Diamond 4
    Hi @LWSpencer42,

    I've passed that on to the team and they're going to discuss it so I'll let you know what comes of that when I hear back!

    For now, the choice is as I've stated I'm afraid!

    Kind regards,
    Alex
    Product Support Engineer | Redgate Software

    Have you visited our Help Center?
  • Alex BAlex B Posts: 1,131 Diamond 4
    Hi @LWSpencer42 ,

    Apologies on the delay for coming back on this.  We're unlikely to implement the specific functionality you are looking for here, however, in SmartAssembly 7.4.0 we added new command-line arguments that could serve as a workaround.

    You said you do lots of nightly builds for which you don't want any data to be added to the database and you don't want any map files created. For such builds it's possible to use the aforementioned command-line arguments to tell SmartAssembly to use a different database, which can be later discarded. Similarly, the map files directory can be discarded as well.

    Workaround (SA 7.4.0+)

    1. Regular builds

    For regular user-facing builds SmartAssembly is configured to:
    • connect to the main SQL Server, e.g. 127.8.9.10\SQLExpress
    • save map files to a file share, e.g. \\builds\map_files

    SmartAssembly is executed the same way it always was, for example:
    SmartAssembly.com /build project.saproj

    2. Nightly builds

    For nightly builds we instruct SmartAssembly on a per-build basis to:
    • use a temporary SQLite database file
    • ...and as a result, a default map files location: %PROGRAMDATA%\Red Gate\SmartAssembly 7\Maps

    SmartAssembly must be executed with additional arguments (see all arguments for database), for example:
    SmartAssembly.com /build project.saproj /dbType=SQLite "/dbPath=%PROGRAMDATA%\Red Gate\SmartAssembly 7\temporary.db"
    After the build, using a method of your choice, you will have to:
    • remove the temporary database file: %PROGRAMDATA%\Red Gate\SmartAssembly 7\temporary.db
    • remove the default map files directory: %PROGRAMDATA%\Red Gate\SmartAssembly 7\Maps

    This way, the primary database and the primary map files folder will not be "swamped" with lots of data that you don't need for your nightly builds.

    I hope that helps and apologies again for the delayed reply.

    Kind regards,
    Alex
    Product Support Engineer | Redgate Software

    Have you visited our Help Center?
Sign In or Register to comment.