@jumagura could you please investigate?
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.
@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.
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.
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
incompatible
section) 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
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
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.
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 ?
Here it is.
This is awesome, this feature is great.
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.
Thanks Richard. I have no idea why it had to take so long!