It seems that there is a problem in some metadata for shared resources (locks).
I renamed a lock and in couple of configurations it seems it has old name stored:
One field failed validation. Conditions.SharedResourceLocks.SharedResourceItem.SharedResource.Name: Shared Resource Name must start with a letter, number or underscore and can only contain letters, numbers, underscores, hyphens. The value of ‘Name’ property is ‘DeliverToTrunk.InProgress’.
DeliverToTrunk.InProgress is the old name, new name is Server.DeliverToReleaseBranch.InProgress which is used in build condition.
Acquire: read lock for '"Server.AM.DeliverToTrunk.InProgress","Single"'
Acquire all: write lock for '"Server.DeliverToReleaseBranch.InProgress","Quota list"'
This blocks configuration change, although it seems I can modify the configuration if I delete the condition (disabling doesn’t help). When I bring back the condition the problem still occurs.
We’re having trouble reproducing your scenario exactly, although we can see that there could be issues with the full stop in the shared resource name. We can reproduce the validation error that you are seeing if we allocate a shared resource with a full stop in the name to a stage rather than a build condition. Where do you see that validation message? Is the shared resource also allocated to a stage in the stage options dialog for one of your configurations?
The full stop is an invalid character for shared resource names. We need to add validation when editing the shared resource to prevent saving with this name. We’re working on that now.
What happens if you remove the full stop character from the shared resource name? Note that it is OK to use the full stop in the namespace but not the name.
The validation error occurs when I try to save any changes made to the configuration.
Validation fails on a lock that is now removed and replaced with new one with a different name and type (quota list).
The removed lock was used in 3 configurations, of which 2 fail to save edited changes due to validation error.
Historically it could be that the lock was allocated to a stage rather then condition but now is not the case.
Full stop in the name is from namespace + name of the lock. See picture bolow:
Do you see the old shared resource name or only the new shared resource name in the Identifier drop down when you edit the condition? Also, do you see the old one at all on the Shared Resources in the Administration section?
Can you run each of the following SQL queries on the database and send us the results?
SELECT *
FROM core_sharedresource s
INNER JOIN core_sharedresourceitem i ON i.sharedresourceid = s.id
INNER JOIN core_sharedresourceitemquota q ON q.sharedresourceitemid = i.id;
SELECT c.Name AS "Config Name", l.*, i.*, s.*
FROM builds_configurationconditionsharedresourcelock l
INNER JOIN builds_configurationcondition cc ON cc.id = l.configurationconditionid
INNER JOIN builds_configuration c ON c.id = cc.configurationid
LEFT OUTER JOIN core_sharedresourceitem i ON l.sharedresourceitemid = i.id
LEFT OUTER JOIN core_sharedresource s ON i.sharedresourceid = s.id OR l.sharedresourceid = s.id;
SELECT c.Name AS "Config Name", l.*, i.*, s.*
FROM builds_stagedefinitionsharedresourcelock l
INNER JOIN builds_stagedefinition sd ON sd.id = l.stagedefinitionid
INNER JOIN builds_configurationversion cv ON cv.id = sd.configurationversionid
INNER JOIN builds_configuration c ON cv.id = c.latestconfigurationversionid
LEFT OUTER JOIN core_sharedresourceitem i ON l.sharedresourceitemid = i.id
LEFT OUTER JOIN core_sharedresource s ON i.sharedresourceid = s.id OR l.sharedresourceid = s.id;
Can you run one more SQL query? The first query was unfortunately too restrictive.
SELECT *
FROM core_sharedresource s
LEFT OUTER JOIN core_sharedresourceitem i ON i.sharedresourceid = s.id
LEFT OUTER JOIN core_sharedresourceitemquota q ON q.sharedresourceitemid = i.id;
We can however see that the old resource names are listed in the second query, and you should be able to get the configurations up and running again by executing the following SQL command:
DELETE FROM builds_stagedefinitionsharedresourcelock WHERE sharedresourceitemid = 'cde4eb44-0474-4d57-8de4-a83a00b30197'
Ensure that the Continua CI Server service is shutdown before running this command and restart after.
Meanwhile, we’re looking into what is causing this issue and what can be done to prevent it reappearing.
Hello Dave,
sorry for the trouble, but I just noticed that indeed we had a second lock “DeliverToTrunk” which indeed had full stop in the name (namespace: “AM”, name: “DeliverToTrunk.InProgress”)
After removing the full stop, everything works fine.
This is not an error
