Mathias Klette [Thu, 2 May 2013 17:00:52 +0000 (19:00 +0200)]
common_code, debian_build: cleanup #5
- added CWD to default ENV
- remove unused variables
- facilitate git submodule more
- change the way of tag handling
- beautifying some parts of the code
Mathias Klette [Thu, 2 May 2013 08:38:14 +0000 (10:38 +0200)]
remove CWD variable from common_code
- which used jenkins provided environment variable 'WORKSPACE'
- this in turns leads to errors in debian_repos2db.sh when no such variable exists
- replaced all occurences of CWD in debian_build with it's corresponding ENV['WORKSPACE'] variable
liveboot: report build status to testlink testcase
The liveboot webinterface creates now the testlink project for every new
liveboot image. The jenkins build script reports if a liveboot image
build was successful or failed to a testlink testcase.
liveboot: report build status to testlink testcase
The liveboot webinterface creates now the testlink project for every new
liveboot image. The jenkins build script reports if a liveboot image
build was successful or failed to a testlink testcase.
Dongsu Park [Wed, 24 Apr 2013 09:19:38 +0000 (11:19 +0200)]
extract_storage: change way of obtaining the last develop build number
This commit includes the following bug fixes.
1. get_last_target_build_no() changes its way of obtaining the last
build number of a given target, e.g. develop. So far the function
has tried to get the most recent subdirectory under
/srv/storage-kernels/develop, for example 412. However, that was
slightly buggy, because it returned a wrong value if no subdirectory
exists. As the subdirectories get cleaned up at the end of this script,
such case can happen actually quite often. Therefore the solution is
to parse tarball's filenames to get the last build number.
2. It changed how to install debian package from feature branches.
Sometimes it's not possible to install a debian package with an
option "-t $DISTRIBUTION", especially when $DISTRIBUTION is the one
for feature branch. So let's add a version number to apt-get install
command, to be more specific. i.e. "package_name=version_number"
3. A small bugfix in case of experimental distribution.
Distribution name for sources.list should be $TARGET_NAME instead of
$DISTRIBUTION, because $DISTRIBUTION does not indicates the name of
an individual feature branch, since the recent change by Mathias.
4. A small bugfix. If $PB_SUITE is an empty string, set TARGET_NAME to
master by default. Otherwise the entire script could sometimes work
in a wrong way.
Dongsu Park [Wed, 24 Apr 2013 09:19:38 +0000 (11:19 +0200)]
extract_storage: change way of obtaining the last develop build number
This commit includes the following bug fixes.
1. get_last_target_build_no() changes its way of obtaining the last
build number of a given target, e.g. develop. So far the function
has tried to get the most recent subdirectory under
/srv/storage-kernels/develop, for example 412. However, that was
slightly buggy, because it returned a wrong value if no subdirectory
exists. As the subdirectories get cleaned up at the end of this script,
such case can happen actually quite often. Therefore the solution is
to parse tarball's filenames to get the last build number.
2. It changed how to install debian package from feature branches.
Sometimes it's not possible to install a debian package with an
option "-t $DISTRIBUTION", especially when $DISTRIBUTION is the one
for feature branch. So let's add a version number to apt-get install
command, to be more specific. i.e. "package_name=version_number"
3. A small bugfix in case of experimental distribution.
Distribution name for sources.list should be $TARGET_NAME instead of
$DISTRIBUTION, because $DISTRIBUTION does not indicates the name of
an individual feature branch, since the recent change by Mathias.
4. A small bugfix. If $PB_SUITE is an empty string, set TARGET_NAME to
master by default. Otherwise the entire script could sometimes work
in a wrong way.
Dongsu Park [Thu, 18 Apr 2013 11:38:58 +0000 (13:38 +0200)]
extract_storage: change build number naming scheme for feature branch
This is only a temporary solution to resolve build number conflicts
on Gentoo systems. Without the change, it's nearly impossible to manage
different ebuilds for both master/develop branches and feature branches.
For the example above, new ebuilds for feature branch (build no. 150)
should be recognized as a newer version than the last develop kernel.
In reality, however, the develop kernel has its build number 395, and
the feature build number 150 will be recognized as its previous version.
To avoid such confusion, change build number naming scheme,
from a simple number to a more precise string according to a format
$(last_develop_buildno).$(feature_buildno)
, where $(last_develop_buildno) is the most recent build number
in the develop branch, and $(feature_buildno) is the current feature
branch's build number. For example, if the last build number of develop
branch is 395, and that of feature branch is 150, then the output string
will be "395.150".
i'm really sad about having to add this disclaimer now, not adding it earlier and letting this code rott this much. its working code, yes, but unreadable too. but it's definitly not too late to clean it all up
Dongsu Park [Thu, 18 Apr 2013 11:38:58 +0000 (13:38 +0200)]
extract_storage: change build number naming scheme for feature branch
This is only a temporary solution to resolve build number conflicts
on Gentoo systems. Without the change, it's nearly impossible to manage
different ebuilds for both master/develop branches and feature branches.
For the example above, new ebuilds for feature branch (build no. 150)
should be recognized as a newer version than the last develop kernel.
In reality, however, the develop kernel has its build number 395, and
the feature build number 150 will be recognized as its previous version.
To avoid such confusion, change build number naming scheme,
from a simple number to a more precise string according to a format
$(last_develop_buildno).$(feature_buildno)
, where $(last_develop_buildno) is the most recent build number
in the develop branch, and $(feature_buildno) is the current feature
branch's build number. For example, if the last build number of develop
branch is 395, and that of feature branch is 150, then the output string
will be "395.150".
i'm really sad about having to add this disclaimer now, not adding it earlier and letting this code rott this much. its working code, yes, but unreadable too. but it's definitly not too late to clean it all up
projects / profitbricks / jenkins-build-scripts.git / log