From: Damien R. <dr...@ma...> - 2013-07-25 09:53:00
Attachments:
release_filelist_new.txt
|
Hi Following a comment by Paul and the subsequent emails about excluding '.travis.yml' from the release tarballs [1], I had a look at the build script to add the file to exclusion list. That's when I noticed that we actually only exclude a very limited number of things from the tarballs, leaving a lot files in there that are only useful for development purposes. Here's what we exclude today: .git/ .gitignore config_inc.php custom_constant_inc.php custom_strings_inc.php custom_functions_inc.php mantis_offline.php web.config packages/ I think that moving forward we should use the following exclusions list: .git* .mailmap .travis.yml build.xml web.config config_inc.php custom_constant*_inc.php custom_functions_inc.php custom_strings_inc.php custom_relationships_inc.php mantis_offline.php mc_config_inc.php docbook/ javascript/dev/ packages/ phing/ tests/ This would result in the attached file list (generated from a 1.2.x nightly build using revised build script [2]) Let me know your thoughts. Damien [1] http://thread.gmane.org/gmane.comp.bug-tracking.mantis.cvs/6364/focus=4501 [2] https://github.com/dregad/mantisbt-tools/blob/buildrelease/buildrelease.py |
From: Robert M. <rob...@gm...> - 2013-07-25 13:41:09
|
On Thu, Jul 25, 2013 at 12:52 PM, Damien Regad <dr...@ma...> wrote: > Hi > > Following a comment by Paul and the subsequent emails about excluding > '.travis.yml' from the release tarballs [1], I had a look at the build > script to add the file to exclusion list. > > That's when I noticed that we actually only exclude a very limited number of > things from the tarballs, leaving a lot files in there that are only useful > for development purposes. > > Here's what we exclude today: > > .git/ > .gitignore > config_inc.php > custom_constant_inc.php > custom_strings_inc.php > custom_functions_inc.php > mantis_offline.php > web.config > packages/ > > I think that moving forward we should use the following exclusions list: > > .git* > .mailmap > .travis.yml > build.xml > web.config > config_inc.php > custom_constant*_inc.php > custom_functions_inc.php > custom_strings_inc.php > custom_relationships_inc.php > mantis_offline.php > mc_config_inc.php > docbook/ > javascript/dev/ > packages/ > phing/ > tests/ > > This would result in the attached file list (generated from a 1.2.x nightly > build using revised build script [2]) > > Let me know your thoughts. Looks good to me ( but haven't tested tough ). Robert > Damien > > > [1] > http://thread.gmane.org/gmane.comp.bug-tracking.mantis.cvs/6364/focus=4501 > [2] > https://github.com/dregad/mantisbt-tools/blob/buildrelease/buildrelease.py > > ------------------------------------------------------------------------------ > See everything from the browser to the database with AppDynamics > Get end-to-end visibility with application monitoring from AppDynamics > Isolate bottlenecks and diagnose root cause in seconds. > Start your free trial of AppDynamics Pro today! > http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk > _______________________________________________ > mantisbt-dev mailing list > man...@li... > https://lists.sourceforge.net/lists/listinfo/mantisbt-dev > -- http://robert.muntea.nu/ |
From: Roland B. <ro...@at...> - 2013-07-25 20:10:02
|
There is one more file in nightly builds which should be removed: config_defaults_inc.php=bak > Robert Munteanu <rob...@gm...> hat am 25. Juli 2013 um 15:41 > geschrieben: > > > On Thu, Jul 25, 2013 at 12:52 PM, Damien Regad <dr...@ma...> wrote: > > Hi > > > > Following a comment by Paul and the subsequent emails about excluding > > '.travis.yml' from the release tarballs [1], I had a look at the build > > script to add the file to exclusion list. > > > > That's when I noticed that we actually only exclude a very limited number of > > things from the tarballs, leaving a lot files in there that are only useful > > for development purposes. > > > > Here's what we exclude today: > > > > .git/ > > .gitignore > > config_inc.php > > custom_constant_inc.php > > custom_strings_inc.php > > custom_functions_inc.php > > mantis_offline.php > > web.config > > packages/ > > > > I think that moving forward we should use the following exclusions list: > > > > .git* > > .mailmap > > .travis.yml > > build.xml > > web.config > > config_inc.php > > custom_constant*_inc.php > > custom_functions_inc.php > > custom_strings_inc.php > > custom_relationships_inc.php > > mantis_offline.php > > mc_config_inc.php > > docbook/ > > javascript/dev/ > > packages/ > > phing/ > > tests/ > > > > This would result in the attached file list (generated from a 1.2.x nightly > > build using revised build script [2]) > > > > Let me know your thoughts. > > Looks good to me ( but haven't tested tough ). > > Robert > > > Damien > > > > > > [1] > > http://thread.gmane.org/gmane.comp.bug-tracking.mantis.cvs/6364/focus=4501 > > [2] > > https://github.com/dregad/mantisbt-tools/blob/buildrelease/buildrelease.py > > > > ------------------------------------------------------------------------------ > > See everything from the browser to the database with AppDynamics > > Get end-to-end visibility with application monitoring from AppDynamics > > Isolate bottlenecks and diagnose root cause in seconds. > > Start your free trial of AppDynamics Pro today! > > http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk > > _______________________________________________ > > mantisbt-dev mailing list > > man...@li... > > https://lists.sourceforge.net/lists/listinfo/mantisbt-dev > > > > > > -- > http://robert.muntea.nu/ > > ------------------------------------------------------------------------------ > See everything from the browser to the database with AppDynamics > Get end-to-end visibility with application monitoring from AppDynamics > Isolate bottlenecks and diagnose root cause in seconds. > Start your free trial of AppDynamics Pro today! > http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk > _______________________________________________ > mantisbt-dev mailing list > man...@li... > https://lists.sourceforge.net/lists/listinfo/mantisbt-dev |
From: Damien R. <dr...@ma...> - 2013-07-25 21:16:15
|
On 2013-07-25 22:09, Roland Becker wrote: > There is one more file in nightly builds which should be removed: > config_defaults_inc.php=bak Yes I noticed that one too as I was updating the build script. This file actually is a byproduct of executing sed to update the version suffix (with the commit's sha). In the script's work-in-progress new version, this file is not generated anymore [1] (if you check the file list I attached in my earlier post, you'll see the file is no longer there). [1] https://github.com/dregad/mantisbt-tools/compare/9b28018...buildrelease#L0R163 |
From: Victor B. <vb...@gm...> - 2013-07-31 03:42:39
|
The list looks good. A couple of suggestions: 1. Should the build script require a clean just extracted from git copy? In such case, should it exclude files like config_inc.php or fail when it finds them, because it is a development work area rather than a clean one for publishing. 2. .gitignore has some excludes that are not in the list you propose. e.g. editor files, libraries that we don't distribute, etc. This is not really relevant if we go with #1. On Thu, Jul 25, 2013 at 2:15 PM, Damien Regad <dr...@ma...> wrote: > On 2013-07-25 22:09, Roland Becker wrote: > > There is one more file in nightly builds which should be removed: > > config_defaults_inc.php=bak > > Yes I noticed that one too as I was updating the build script. > > This file actually is a byproduct of executing sed to update the version > suffix (with the commit's sha). > > In the script's work-in-progress new version, this file is not generated > anymore [1] (if you check the file list I attached in my earlier post, > you'll see the file is no longer there). > > [1] > > https://github.com/dregad/mantisbt-tools/compare/9b28018...buildrelease#L0R163 > > > > > ------------------------------------------------------------------------------ > See everything from the browser to the database with AppDynamics > Get end-to-end visibility with application monitoring from AppDynamics > Isolate bottlenecks and diagnose root cause in seconds. > Start your free trial of AppDynamics Pro today! > http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk > _______________________________________________ > mantisbt-dev mailing list > man...@li... > https://lists.sourceforge.net/lists/listinfo/mantisbt-dev > |
From: John R. <jo...@no...> - 2013-07-31 04:04:57
|
On Tue, Jul 30, 2013 at 8:42 PM, Victor Boctor <vb...@gm...> wrote: > > 1. Should the build script require a clean just extracted from git copy? > In such case, should it exclude files like config_inc.php or fail when it > finds them, because it is a development work area rather than a clean one > for publishing. > Considering that the build scripts already provide a method for forcing a temporary/fresh git checkout for each build, I don't think we should be forcing *all* builds to happen this way. Why prevent someone from being able to experiment with making builds from a local working copy if they want to test changes or build from an unofficial git repo? I think the current practice of just stripping out files that shouldn't be part of a proper release is still the way to go. John Reese noswap.com |
From: Victor B. <vb...@gm...> - 2013-07-31 04:33:02
|
How about forcing the clean build in the nightly builds and releases, but keep the current feature for developer workflows. Just depending on exclusions works but can bundle files that are not part of git but are in gitignore. On Jul 30, 2013 9:05 PM, "John Reese" <jo...@no...> wrote: > > On Tue, Jul 30, 2013 at 8:42 PM, Victor Boctor <vb...@gm...> wrote: > >> >> 1. Should the build script require a clean just extracted from git copy? >> In such case, should it exclude files like config_inc.php or fail when it >> finds them, because it is a development work area rather than a clean one >> for publishing. >> > > Considering that the build scripts already provide a method for forcing a > temporary/fresh git checkout for each build, I don't think we should be > forcing *all* builds to happen this way. Why prevent someone from being > able to experiment with making builds from a local working copy if they > want to test changes or build from an unofficial git repo? I think the > current practice of just stripping out files that shouldn't be part of a > proper release is still the way to go. > > > John Reese > noswap.com > > > ------------------------------------------------------------------------------ > Get your SQL database under version control now! > Version control is standard for application code, but databases havent > caught up. So what steps can you take to put your SQL databases under > version control? Why should you start doing it? Read more to find out. > http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk > _______________________________________________ > mantisbt-dev mailing list > man...@li... > https://lists.sourceforge.net/lists/listinfo/mantisbt-dev > > |
From: Victor B. <vb...@gm...> - 2013-07-31 04:35:26
|
Also I wonder if "git archive" can be a good building block for this. On Jul 30, 2013 9:32 PM, "Victor Boctor" <vb...@gm...> wrote: > How about forcing the clean build in the nightly builds and releases, but > keep the current feature for developer workflows. > > Just depending on exclusions works but can bundle files that are not part > of git but are in gitignore. > On Jul 30, 2013 9:05 PM, "John Reese" <jo...@no...> wrote: > >> >> On Tue, Jul 30, 2013 at 8:42 PM, Victor Boctor <vb...@gm...> wrote: >> >>> >>> 1. Should the build script require a clean just extracted from git copy? >>> In such case, should it exclude files like config_inc.php or fail when it >>> finds them, because it is a development work area rather than a clean one >>> for publishing. >>> >> >> Considering that the build scripts already provide a method for forcing a >> temporary/fresh git checkout for each build, I don't think we should be >> forcing *all* builds to happen this way. Why prevent someone from being >> able to experiment with making builds from a local working copy if they >> want to test changes or build from an unofficial git repo? I think the >> current practice of just stripping out files that shouldn't be part of a >> proper release is still the way to go. >> >> >> John Reese >> noswap.com >> >> >> ------------------------------------------------------------------------------ >> Get your SQL database under version control now! >> Version control is standard for application code, but databases havent >> caught up. So what steps can you take to put your SQL databases under >> version control? Why should you start doing it? Read more to find out. >> >> http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk >> _______________________________________________ >> mantisbt-dev mailing list >> man...@li... >> https://lists.sourceforge.net/lists/listinfo/mantisbt-dev >> >> |
From: John R. <jo...@no...> - 2013-07-31 05:15:40
|
AFAIK, the nightly builds are already using the --fresh option. :) John Reese noswap.com On Tue, Jul 30, 2013 at 9:35 PM, Victor Boctor <vb...@gm...> wrote: > Also I wonder if "git archive" can be a good building block for this. > On Jul 30, 2013 9:32 PM, "Victor Boctor" <vb...@gm...> wrote: > >> How about forcing the clean build in the nightly builds and releases, >> but keep the current feature for developer workflows. >> >> Just depending on exclusions works but can bundle files that are not part >> of git but are in gitignore. >> On Jul 30, 2013 9:05 PM, "John Reese" <jo...@no...> wrote: >> >>> >>> On Tue, Jul 30, 2013 at 8:42 PM, Victor Boctor <vb...@gm...>wrote: >>> >>>> >>>> 1. Should the build script require a clean just extracted from git >>>> copy? In such case, should it exclude files like config_inc.php or fail >>>> when it finds them, because it is a development work area rather than a >>>> clean one for publishing. >>>> >>> >>> Considering that the build scripts already provide a method for forcing >>> a temporary/fresh git checkout for each build, I don't think we should be >>> forcing *all* builds to happen this way. Why prevent someone from being >>> able to experiment with making builds from a local working copy if they >>> want to test changes or build from an unofficial git repo? I think the >>> current practice of just stripping out files that shouldn't be part of a >>> proper release is still the way to go. >>> >>> >>> John Reese >>> noswap.com >>> >>> >>> ------------------------------------------------------------------------------ >>> Get your SQL database under version control now! >>> Version control is standard for application code, but databases havent >>> caught up. So what steps can you take to put your SQL databases under >>> version control? Why should you start doing it? Read more to find out. >>> >>> http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk >>> _______________________________________________ >>> mantisbt-dev mailing list >>> man...@li... >>> https://lists.sourceforge.net/lists/listinfo/mantisbt-dev >>> >>> > > ------------------------------------------------------------------------------ > Get your SQL database under version control now! > Version control is standard for application code, but databases havent > caught up. So what steps can you take to put your SQL databases under > version control? Why should you start doing it? Read more to find out. > http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk > _______________________________________________ > mantisbt-dev mailing list > man...@li... > https://lists.sourceforge.net/lists/listinfo/mantisbt-dev > > |
From: Damien R. <dr...@ma...> - 2013-07-31 08:05:43
|
On 2013-07-31 07:15, John Reese wrote: > On Tue, Jul 30, 2013 at 9:35 PM, Victor Boctor wrote: > > > 1. Should the build script require a clean just > > extracted from git copy? In such case, should it > > Considering that the build scripts already provide a method > for forcing a temporary/fresh git checkout for each build, I > don't think we should be forcing *all* builds to happen this > way. Why prevent someone from being able to experiment with > making builds from a local working copy if they want to test > changes or build from an unofficial git repo? I think the > current practice of just stripping out files that shouldn't > be part of a proper release is still the way to go. +1 > > How about forcing the clean build in the nightly builds and > > releases, but keep the current feature for developer workflows. > > AFAIK, the nightly builds are already using the --fresh option. Correct. FYI the command-line used for nightly builds is [1] buildrelease-repo.py --auto-suffix --ref master-1.2.x,master --fresh --docbook $pathBuilds --auto-suffix Automatically append the Git hash to the version suffix --ref Build a release for named refs <ref> --fresh Create a fresh clone at repository path, or temporary path > > Also I wonder if "git archive" can be a good building block for this. Maybe, but since we already have John's build script working as it is, I don't think it's really worth the effort to change the implementation (if it ain't broke...); after all, all git archive does is package a zip or tar command which is easy enough to do, plus some magic with files timestamps which is just a cosmetic nice to have IMHO. Also the problem would be that git archive does not allow to manually exclude files, so it would either have to be done directly in the git repo prior to archiving (potentially impacting the repository's working directory if not using a fresh copy), or after the fact using the relevant tar/zip command (not very efficient). > > 2. .gitignore has some excludes that are not in the list you > > propose. e.g. editor files, libraries that we don't distribute, > > etc. This is not really relevant if we go with #1. I initially considered including the whole .gitignore file, but realized that a smart parsing logic would have to be implemented to factor in the exclusions (e.g. for plugins) - so I decided to keep things simple. Damien [1] https://github.com/mantisbt/mantisbt-tools/blob/master/nightly-builds.sh#L57 |