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
Dongsu Park [Wed, 17 Apr 2013 12:05:44 +0000 (14:05 +0200)]
extract_storage_kernel+modules: add support for feature branches
Now extract_storage_kernel+modules is able to copy kernel images
from feature branches. Output tar.gz file will be stored under
/srv/storage-kernels/$DISTRIBUTION/, where $DISTRIBUTION indicates
target name for a feature branch. (e.g. dev-feature-ssdcache-all)
directly syncing to liveboot-dcmanager module leads to erase of SSH and PXE configurations,
liveboot rsync stays at it is right now but probably we can sync to localhost to transfer
images from /srv/mirror/liveboot to the intended location of /srv/tftp/liveboot-dcmanager
projects / profitbricks / jenkins-build-scripts.git / log