Hi, we need to move Continua/PostgreSQL/FinalBuilder to a new Windows Server, so I was wondering if there is a step by step guide somewhere?
Hi Lars,
I just added a guide to the Continua CI documentation. See Migrating to a New Server.
Let us know how you get on.
1 Like
Not so good.
Would you like me to open a ticket and attach the backup?
I stopped the old service.and ran
pg_dump.exe -h localhost -p 9001 -U postgres -F p -c -f D:\Install\continua_backup.bak ContinuaCI
and used the password from C:\Program Files\VSoft Technologies\ContinuaCI\Server\PostgreSQL\passwd on the old server
Copied the backup file, and ran
psql.exe -h localhost -b -p 9001 -U postgres ContinuaCI < C:\temp\continua_backup.bak
using the password from C:\Program Files\VSoft Technologies\ContinuaCI\Server\PostgreSQL\passwd on the new server
It gave me gives me some errors, as you can see below.
ERROR: cannot drop constraint pk_builds_build on table public.builds_build because other objects depend on it
DETAIL: constraint fk_builds_unittest_to_builds_build on table public.builds_unittest depends on index public.pk_builds_build
HINT: Use DROP ... CASCADE to drop the dependent objects too.
STATEMENT: ALTER TABLE ONLY public.builds_build DROP CONSTRAINT pk_builds_build;
–
ERROR: cannot drop table public.builds_build because other objects depend on it
DETAIL: constraint fk_builds_unittest_to_builds_build on table public.builds_unittest depends on table public.builds_build
HINT: Use DROP ... CASCADE to drop the dependent objects too.
STATEMENT: DROP TABLE public.builds_build;
–
ERROR: cannot drop schema public because other objects depend on it
DETAIL: table public.builds_build depends on schema public
table public.builds_unittest depends on schema public
view public.builds_unittestfixturesummary_view depends on schema public
view public.builds_unittestnamespacesummary_view depends on schema public
view public.builds_unittestassemblysummary_view depends on schema public
HINT: Use DROP ... CASCADE to drop the dependent objects too.
STATEMENT: DROP SCHEMA public;
–
ERROR: relation "builds_build" already exists
STATEMENT: CREATE TABLE public.builds_build (
id integer NOT NULL,
started timestamp without time zone,
finished timestamp without time zone,
workspaceid uuid,
configurationversionid uuid NOT NULL,
userid uuid,
triggerid uuid,
onlynotifytriggeringusers boolean DEFAULT false NOT NULL,
quietperiodlength integer,
quietperiodexpiry timestamp without time zone,
priority integer DEFAULT 1 NOT NULL,
buildnumber integer DEFAULT 1 NOT NULL,
version character varying(128) DEFAULT '1.0.0.0'::character varying NOT NULL,
summarystate integer DEFAULT 2 NOT NULL,
timeonqueue bigint DEFAULT 0 NOT NULL,
pinned timestamp without time zone,
cleanedup boolean DEFAULT false NOT NULL,
variablenamespaceid uuid NOT NULL,
usesdefaultbranch boolean DEFAULT false NOT NULL,
isfeaturebranchbuild boolean DEFAULT false NOT NULL,
configurationid uuid DEFAULT '00000000-0000-0000-0000-000000000000'::uuid NOT NULL,
queued timestamp without time zone,
pincomment character varying(256),
pinuserid uuid,
hasnewchanges boolean DEFAULT false NOT NULL,
buildsuccess boolean DEFAULT false NOT NULL,
branches character varying(10240),
state integer DEFAULT 0 NOT NULL,
status_message character varying(10240),
status_datetime timestamp without time zone DEFAULT '2013-11-26 14:07:45'::timestamp without time zone NOT NULL,
runningactionname character varying(10240),
runningactionid uuid,
runningactiontype character varying(10240),
runningactionmessage character varying(10240),
accumulatechanges boolean DEFAULT false NOT NULL,
created timestamp without time zone,
triggeringrepositoryid uuid,
lastcontinued timestamp without time zone,
requeuedbuildid integer,
counted integer DEFAULT 0 NOT NULL,
repobranchhashcode text
);
ALTER TABLE
–
ERROR: duplicate key value violates unique constraint "pk_builds_build"
DETAIL: Key (id)=(65101) already exists.
CONTEXT: COPY builds_build, line 1
STATEMENT: COPY public.builds_build (id, started, finished, workspaceid, configurationversionid, userid, triggerid, onlynotifytriggeringusers, quietperiodlength, quietperiodexpiry, priority, buildnumber, version, summarystate, timeonqueue, pinned, cleanedup, variablenamespaceid, usesdefaultbranch, isfeaturebranchbuild, configurationid, queued, pincomment, pinuserid, hasnewchanges, buildsuccess, branches, state, status_message, status_datetime, runningactionname, runningactionid, runningactiontype, runningactionmessage, accumulatechanges, created, triggeringrepositoryid, lastcontinued, requeuedbuildid, counted, repobranchhashcode) FROM stdin;
setval
–
ERROR: multiple primary keys for table "builds_build" are not allowed
STATEMENT: ALTER TABLE ONLY public.builds_build
ADD CONSTRAINT pk_builds_build PRIMARY KEY (id);
–
ERROR: multiple primary keys for table "builds_build" are not allowed
STATEMENT: ALTER TABLE ONLY public.builds_build
ADD CONSTRAINT pk_builds_build PRIMARY KEY (id);Hi Lars,
Usually the -c option on the pg_dump command adds the SQL statements to drop the objects in the existing database in the correct order, so I’m not sure why you are seeing these errors. Just tested restoring over an existing database with the same parameters and it worked without errors.
Did you upgrade the old service to the latest version, before running the backup? If not, then the new database may have a different schema to the old one.
Try dropping and recreating the existing database before running the psql.exe command to restore. Run the following statements in the PGAdmin4 query tool:
DROP DATABASE ContinuaCI
CREATE DATABASE ContinuaCI
1 Like
Yes, Continua was upgraded to the latest version, so the same version was running at both the old and the new server.
Dropping and recreating the database did the trick.
It may have been that I did multiple restore attempts which caused the dependencies.
1 Like
Are there any special steps required to migrate our concurrent build licenses to the new server?
You may want to include that drop/create trick in the migration guide (or the backup/restore guide).
No, just delete them from the old one, then upload file to the new one.
Yes, will do
On the page http://localhost:8080/administration/ci/collectors/properties
Env.COMPUTERNAME contained the OLD computer name
Server.HostUrl needed to be edited, as it contains the OLD URL
But my building still wont kick off - it complains
Stage Awaiting Agent
No agents are currently available to execute the stage.
devapp668wms001: The expression [’$Agent.Hostname$’ equals ‘dev10002’] evaluated to False. ‘devapp668wms001’ does not equal ‘dev10002’. This may be because a required tool is not installed on the agent.
Where do I change $Agent.Hostname$ ?
Yes, I’ll add this to the guide.
I suspect that there is an Agent Requirement in the Stage Options which needs changing.
1 Like
Yes, you were right. There were Agent Requirements present.
Thanks!
https://wiki.finalbuilder.com/display/continua/PowerShell+Action
seems a bit outdated.
Also - How can I set the default PowerShell version in Continua CI to PS Core 7 ?
Yes, the documentation for this action is a little outdated. We’ll change the default version and property collector for new PowerShell actions for the next version of Continua CI.
1 Like