 |
History
| Log In
|
|
|
|
Thank you for taking a look Jason.
I attempted to reproduce the issue by creating some new templates and projects, but in doing so somehow the original project has gotten corrupted, as I now receive errors like: triggers Triggers allow you to specify when builds will be run for this project. Failed to render form. Unexpected class java.lang.NullPointerException: null And: The following projects have invalid configuration, and cannot be used for building or reporting until rectified: I will back up the database and issue the command you recommend. I will probably also delete the errant project and template and try again. If it will help you diagnose the issue, I can send you a copy of the database backup. Thank you, Chuck The server had been using the embedded database. Presumably there is no way to issue commands to the embedded database. I will attempt to migrate to a MySQL database and then proceed.
I was able to successfully migrate the database. Your 'delete' command deleted 1 row from the database. However, the server will no longer start. Here is the error I receive:
java.lang.NullPointerException at com.zutubi.pulse.master.tove.config.project.triggers.BuildCompletedTriggerConfiguration.populateDataMap(BuildCompletedTriggerConfiguration.java:121) at com.zutubi.pulse.master.tove.config.project.triggers.BuildCompletedTriggerConfiguration.newTrigger(BuildCompletedTriggerConfiguration.java:109) at com.zutubi.pulse.master.tove.config.project.triggers.TriggerManager.createState(TriggerManager.java:75) at com.zutubi.pulse.master.tove.config.project.triggers.TriggerManager.createState(TriggerManager.java:19) at com.zutubi.tove.config.ConfigurationStateManager$1.execute(ConfigurationStateManager.java:66) at com.zutubi.tove.transaction.TransactionManager.runInTransaction(TransactionManager.java:254) at com.zutubi.tove.config.ConfigurationStateManager.createAndAssignState(ConfigurationStateManager.java:60) at com.zutubi.tove.config.DefaultConfigurationProvider.ensureExternalStateIsInSyncWithConfiguration(DefaultConfigurationProvider.java:75) at com.zutubi.tove.config.DefaultConfigurationProvider.init(DefaultConfigurationProvider.java:53) at com.zutubi.pulse.master.bootstrap.DefaultSetupManager.requestSetupComplete(DefaultSetupManager.java:526) at com.zutubi.pulse.master.bootstrap.DefaultSetupManager$3.run(DefaultSetupManager.java:499) at com.zutubi.pulse.master.security.AcegiUtils.runAsUser(AcegiUtils.java:69) at com.zutubi.pulse.master.security.AcegiUtils.runAsSystem(AcegiUtils.java:86) at com.zutubi.pulse.master.bootstrap.DefaultSetupManager.requestUpgradeComplete(DefaultSetupManager.java:476) at com.zutubi.pulse.master.bootstrap.DefaultSetupManager.requestLicenseComplete(DefaultSetupManager.java:431) at com.zutubi.pulse.master.bootstrap.DefaultSetupManager.requestRestoreComplete(DefaultSetupManager.java:391) at com.zutubi.pulse.master.bootstrap.DefaultSetupManager.handleRestorationProcess(DefaultSetupManager.java:723) at com.zutubi.pulse.master.bootstrap.DefaultSetupManager.requestDbComplete(DefaultSetupManager.java:306) at com.zutubi.pulse.master.bootstrap.DefaultSetupManager.handleDbMigration(DefaultSetupManager.java:262) at com.zutubi.pulse.master.bootstrap.DefaultSetupManager.handleDbSetup(DefaultSetupManager.java:245) at com.zutubi.pulse.master.bootstrap.DefaultSetupManager.requestDataComplete(DefaultSetupManager.java:207) at com.zutubi.pulse.master.bootstrap.DefaultSetupManager.startSetupWorkflow(DefaultSetupManager.java:131) at com.zutubi.pulse.master.bootstrap.tasks.ProcessSetupStartupTask.run(ProcessSetupStartupTask.java:60) at com.zutubi.pulse.master.security.PulseThreadFactory$DelegatingRunnable.run(PulseThreadFactory.java:33) at java.lang.Thread.run(Unknown Source) I have also tried deleting all triggers named 'scm trigger' which doesn't help. I think I will go with a fresh setup now. I didn't have many projects so it shouldn't be too painful. Hi Chuck,
OK, it looks like just deleting that row was insufficient as the config system (outside the database) still wanted to recreate it. The odd thing, though, is that it is trying to recreate a build completed trigger, not an SCM trigger. I'm not sure why that would be, unless the wrong trigger was deleted, or the config is really out of whack somehow. If you have not started again, I would be happy to take a look at your data and try to restore it to a working state. Just let me know and I can give instructions to upload your config and database. Hello Jason, thanks for your continued help. I managed to reproduce the issue consistently. Here are the steps:
1. Start a fresh 2.0.22 server (Windows XP service), using the embedded database. 2. Under administration | projects: 3. Add a new template to global project template, call it 'template1' 4. Add a new template to 'template1', call it 'subtemplate1' 5. Add a new project to 'subtemplate1', call it 'subproject1' 6. Add a new template to 'template1', call it 'subtemplate2' 7. Configure 'subtemplate2' to add a 'build completed' trigger for 'subproject1' ('success' state), calling it 'build' 8. Add a new template to 'subtemplate2', call it 'subsubtemplate1' 9. Configure 'subsubtemplate1' to add a 'cron trigger' named 'nightly' with 'cron string' = '0 0 1 * * ?' 10. Add a new project to 'subsubtemplate1', call it 'subsubproject1' 11. Examine the project 'subsubproject1'; note the triggers are correct 12. Configure 'subsubtemplate1' to hide the triggers 'scm trigger' and 'build' 13. Add a new project to 'subsubtemplate1', call it 'subsubproject2' 14. Examine the project 'subsubproject2'; note the trigger 'scm trigger' appears as 'overridden' 15. Configure 'subsubtemplate1' to attempt to restore the 'scm trigger' 16. You will receive the error 'java.lang.NullPointerException', or 'com.zutubi.pulse.master.scheduling.SchedulingException: A trigger with name scm trigger and group project:98306 has already been scheduled.' (if the recipe queue is not empty?) 17. Further project configuration browsing (i.e., trying to look at the triggers) may result in 'Invalid transaction status: rollingback' errors. 18. Shortly thereafter the server may become unusable (unresponsive to http requests). Hope that helps. Chuck Thanks to the extra details I was able to find the root of this problem: the project wizard adds a default scm trigger to a project if its parent does not have one which it will inherit. Unfortunately, if an ancestor project has the trigger and then it is hidden, the wizard will still add it. This violates an invariant of the templating system: you should not be able to override a hidden path. So there are two problems: the wizard needs to recognise not to try adding the trigger in this case, and the underlying config system should reject it to preserve consistency.
Fixed in change 5853. I have verified that this is fixed in version 2.0.29. Thank you!
Chuck |
|||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Resolved
3
Error hiding 'scm trigger' from a project template
Thanks for the report. I tried a simple test here with a layout like:
template - defines scm trigger
+ child template
+ concrete project 1
+ concrete project 2
I hid the trigger in child template then restored it and it worked OK. I also tried to add an scm trigger to one of the concrete projects while the child template was still hiding its trigger, but Pulse (correctly) prevented me from doing so. Finally I tried pausing the trigger in a concrete project before hiding/restoring it, but still didn't see the problem.
Obviously I am missing the sequence of operations required to reproduce the behavior (which is certainly a bug). Do you remember anything else significant in the history of this trigger/these projects that may help?
To fix the problem, you will probably need to shut down Pulse and delete the relevant trigger from your Pulse database. The trigger can be deleted using the SQL statement:
delete from LOCAL_TRIGGER where TRIGGER_NAME = 'scm trigger' and TRIGGER_GROUP = 'project:2949120'
I strongly recommend backing up your database first just in case.