@jumagura could you please investigate?
1 Like
Sure thing, and I apologize if I’m not completely certain about the steps, as this is the first time I’ve been assigned to review this. I believe the following steps are necessary:
- Access the stable version at stable.discourse.pluginmanager.org. Credentials may be required to review the logs.
- I attempted to log in at discourse.pluginmanager.org but was not allowed, probably because only admins can access the site. Is this the case?
Could you please confirm if these are the correct steps? Thank you!
The second site no longer exists.
Only the first site remains but that’s all you should need.
This guide should still be relevant:
https://coop.pavilion.tech/t/how-to-action-canary-server-issues/2749?u=merefield
I’ll confirm my morning if I have access then I should be able to add your key.
I do have access and can add your key.
@jumagura you should only need ssh access …
please PM me your public key and I’ll confirm when I’ve added it.
1 Like
@jumagura can you confirm one thing:
if, locally, you drop the test database, switch to stable, recreate, migrate and run all tests via command line and/or chrome, what do you see?
that should hopefully recreate the same conditions as on canary (albeit without the plugin guard).
Or maybe (as Richard suggested to me in a DM) this was incompatible at one point but is no longer and you just have to move the plugin back from incompatible again.
Hi @angus @richard @merefield,
I found that the update made to fix a deprecation in the main branch is causing problems in stable because it’s not needed there. I made a PR to undo that change in the stable branch.
But now I have a problem with the CI workflow in GitHub. Right now, the stable branch of the plugin is tested with Discourse’s main branch, but it should be tested with Discourse’s stable branch. This will probably cause an error in the CI workflow.
I know we need to change the CI workflow to test the stable branch of the plugin with Discourse’s stable branch, but I’m not sure how to change the workflow YAML file. Can you please help me with this? Your help would be really important to me, and I thank you for it.
1 Like
From what I reviewed. None of the stable branches of official discourse plugins run CI tests. Those are for main branches only. What I suggest is to keep CI workflow test only for main branch. And let the PMS guard the stable branch. With that approach we can continue developing and maintaining this plugin.
1 Like
what exactly do you mean by that?
if tests aren’t run against stable in CI, how will PMS help run tests?
However, I would agree that running tests on Stable may be overkill because there should be no significant change to stable branch of Discourse.
However they do backport, so change does happen. Perhaps consider this a low priority enhancement for now and deal with it in a separate Topic.
Arguably the most important thing here, for now though, is getting the Dashboard showing the appropriate status, so I’d suggest the following actions:
- fix stable branch of CW so locally tests run successfully against stable Discourse, push any fixes to stable.
- rebuild using Plugin Guard (not standard build command!) on canary stable making sure app.yml has all plugins cloned as normal (ie Custom Wizard is not in
incompatiblesection) and it’s cloning the stable branch.
FWIW, upgrading Custom Wizard to its last version on a Discourse instance with the latest stable Discourse version will break it. I mean it’s not just that the plugin doesn’t work: the whole forum stops loading due to it. This seems to have been due to recent changes.
Console error
loader.js:247 Uncaught (in promise) Error: Could not find module `discourse/components/modal/insert-hyperlink` imported from `discourse/plugins/discourse-custom-wizard/discourse/components/custom-wizard-composer-editor`
at loader.js:247:1
at c (loader.js:258:1)
at s.findDeps (loader.js:168:1)
at c (loader.js:262:1)
at requireModule (loader.js:24:1)
at a.get (index.js:24:1)
at e._extractDefaultExport (index.js:380:1)
at e.resolveOther (index.js:109:1)
at e.resolveOther (resolver.js:241:1)
at e.resolve (index.js:155:1)
at index.js:962:1
at v.resolve (index.js:630:1)
at v.resolve (index.js:632:1)
at e.resolveRegistration (registry_proxy.js:29:1)
at colocated-template-overrides.js:31:1
at Object.eachThemePluginTemplate (colocated-template-overrides.js:41:1)
at Object.initialize (colocated-template-overrides.js:22:1)
at o.initialize (app.js:41:1)
at index.js:126:1
at e.each (dag-map.js:192:1)
at e.walk (dag-map.js:121:1)
at e.each (dag-map.js:66:1)
at e.topsort (dag-map.js:72:1)
at e._runInitializer (index.js:138:1)
at e.runInstanceInitializers (index.js:124:1)
at e._bootSync (instance.js:101:1)
at e.didBecomeReady (application.js:650:1)
at p.invoke (queue.ts:201:14)
at p.flush (queue.ts:98:13)
at h.flush (deferred-action-queues.ts:75:19)
at q._end (index.ts:616:32)
at _boundAutorunEnd (index.ts:257:12)
Wasn’t aware that the plugin had a stable branch. Is that what is recommended for those running Discourse on the stable branch or there is no relation?
Yes, hence the title of this Topic.
@jumagura is in the process of resolving this.
Please consult the dashboard in future so you can choose to hold off on upgrades when it’s showing incompatible.
Yes 
1 Like
Hi @merefield.
This PR should solve the problem on stable.
I’m in process of working on 2. I’ll let you know when I’m done
2 Likes
Great progress, thanks Marcos!
Thanks for raising this @mentalstring - we really need to make that super obvious.
Is it possible to automatically peg those on stable core to the stable CWP branch?
The other way to tackle that is to make it really clear in the documentation that this is the case.
1 Like
An additional issue is that the .discourse-compatibility file on main has not been updated to guard against people on stable updating to 690f12ee3e2c793ef93892078bb007bafd11dd7e or beyond.
Can you please take care of that as well @jumagura ?
2 Likes
Here it is.
This is awesome, this feature is great.
1 Like
Over three weeks and still we have this?
This was a high-priority ticket, it really should have been closed out within 3 days at most.
@jumagura can you address this urgently please?
I’ve moved it back to the supported plugin list and rebuilt stable canary.
1 Like
Thanks Richard. I have no idea why it had to take so long!