Workflow for multiple branches (feature branches)

18 views
Skip to first unread message

W. Martin Borgert

unread,
May 8, 2013, 5:22:14 AM5/8/13
to bit...@googlegroups.com
Hi,

in one project, we are working with feature branches.
Unfortunately, the branches are not yet automatically
compiled and tested by Bitten.

Is there any way to create all the necessary rules and
recipes for a branch automatically? Doing it manually is
too much work and error-prone.

It seems to work with Jenkins:
http://entagen.github.io/jenkins-build-per-branch/
However, I like to stay with something Python based.

How do other people solve this? TIA!

Cheers

(I know, that in the "real" C/I philosophy, it is frown
upon not integrating in the main line ASAP, but that's
another discussion.)

Roland Wilczek

unread,
May 8, 2013, 6:14:05 AM5/8/13
to bit...@googlegroups.com
Hi,

I am using SQL-scripts at the psql-commandline to mass-copy configs, platform
and rules from one location to another, doing the necessary modifications with
SQL-replace(). This is much faster and less errorprone than manually copying
the stuff using the web-ui. That is: whoever creates a new branch and wants
Bitten-support on it, has to tell me.

Theoretically one could have a build-configuration listening to the parent-
branch of the featurebranches and could then perform the SQL-scripts as a
build. Never tried this, but you would have to analyze the commits and perform
the copy/modify only on "svn cp" resulting in new folders in the parent-
branch. Unfortunately the trac-/bitten-API does not seem to support such an
introspection. I am quite happy with my solution.

Here is what I do in PostgreSQL.
The scripts below are somewhat simplified in that, that a build-configuration
has to provide it's 'path' as a suffix of it's name. With some project-specific
convention, you should be able to have other options to identify the
configuration's primary keys in that LIKE-expressions.

BEGIN TRANSACTION;

/*
* Copy build configurations from sourceBranch to targetBranch
*/
INSERT INTO bitten_config
(name, path, active, recipe, min_rev, max_rev, label, description)
SELECT
replace(name, 'sourceBranch', 'targetBranch'),
replace(path, 'sourceBranch', 'targetBranch'),
0, /* active: 1 */
replace(recipe, 'sourceBranch', 'targetBranch'),
'4711', /* first revision to be built a targetBranch */
'HEAD',
replace(label, 'sourceBranch', 'targetBranch'),
replace(description, 'sourceBranch', 'targetBranch')

FROM bitten_config
WHERE name LIKE '%sourceBranch';

/*
* Copy target platforms from sourceBranch to targetBranch
*/
INSERT INTO bitten_platform (config, name)
SELECT replace(config, 'sourceBranch', 'targetBranch'), name
FROM bitten_platform
WHERE config LIKE '%sourceBranch';

/*
* Copy rules from sourceBranch to targetBranch
*/
INSERT INTO bitten_rule (id, propname, pattern, orderno)
SELECT PF.new_platform_id, bitten_rule.propname, bitten_rule.pattern,
bitten_rule.orderno
FROM bitten_rule
INNER JOIN (
SELECT source.id AS old_platform_id, target.id AS new_platform_id
FROM bitten_platform AS source
INNER JOIN bitten_platform AS target
ON source.config = replace(target.config, 'targetBranch', 'sourceBranch')
AND source.name = target.name
WHERE source.config LIKE '%sourceBranch'
AND target.config LIKE '%targetBranch'
) AS PF
ON (bitten_rule.id = PF.old_platform_id);

--ROLLBACK;
--COMMIT;

When a featurebranch is reintegrated, you want to delete the build-
configurations (and all their artifacts in the database) again.
The following does the job. As a side-effect other orphanes are cleaned up too,
which somewhat attenuates the outcomes of bitten's lack of db-supported
referential integrity.

BEGIN TRANSACTION;

-- Delete build configurations from branch
DELETE FROM bitten_config WHERE name LIKE '%foobar';

-- Delete target platforms from branch
DELETE FROM bitten_platform WHERE config NOT IN (SELECT name FROM
bitten_config);

-- Delete rules without platform
DELETE FROM bitten_rule WHERE id NOT IN (SELECT id FROM bitten_platform);

-- Delete orphaned builds
DELETE FROM bitten_build WHERE platform NOT IN (SELECT id FROM
bitten_platform);

-- Delete orphaned reports
DELETE FROM bitten_report WHERE build NOT IN (SELECT id FROM bitten_build);

-- Delete orphaned steps
DELETE FROM bitten_step WHERE build NOT IN (SELECT id FROM bitten_build);

-- Delete orphaned slaves
DELETE FROM bitten_slave WHERE build NOT IN (SELECT id FROM bitten_build);

-- Delete orphaned logs
DELETE FROM bitten_log WHERE build NOT IN (SELECT id FROM bitten_build);

-- Delete orphaned errors
DELETE FROM bitten_error WHERE build NOT IN (SELECT id FROM bitten_build);

-- Delete orphaned report_items. You may have the time to have coffee(s) here.
DELETE FROM bitten_report_item WHERE report NOT IN (SELECT id FROM
bitten_report);

--ROLLBACK;
--COMMIT;

This does not delete bitten's logfiles from disk. I don't worry too much about
that and use a cronjob to cleanup the log-directory like that:

# Delete Bitten's logfiles each night at 2:00h, if they are older than 180 days
0 2 * * * find /trac/log/bitten -mtime +180 -type f -print | xargs rm -rf

Hope, that helps

- Roland Wilczek
--

Reply all
Reply to author
Forward
0 new messages