In complex applications, routes are generally stored in source/version control.
That's not the case in Arc where there's no single source of truth.
It would be helpful if resolver config (the regex, content source, etc) could be set up from code so that when a bug gets resolved for example, this could help prevent regressions.
Claire Campbell
I see that this is marked as "Shipped". I do not see anything in PageBuilder or documentation on how resolvers have version control. Could someone provide a link?
Hi Tania, thanks for the update. Are there any approaches that you would like to brainstorm here with the team since we have been so close to the use cases discussed?
Thanks for these additional details - we're considering a few approaches to address these issues and will circle back with additional documentation and ways to address the pain points.
> Resolvers break every time that someone edits a Content Source. In production.
Concrete example: We have a content source called "content-by-x.js". Someone renames that content source to "content-by-y.js". If you deploy a bundle to production, every Resolver that used "content-by-x.js" is now broken. To fix, you have to manually go through each Resolver and change each Content Source to "content-by-y.js" & re-configure the parameters.
As a team's website gets more complex or their team gets bigger, it's obvious how this'd be an issue. The person or process deploying a bundle change (e.g. CircleCI) has no idea that the Resolvers will all be broken.
Worse yet, to configure the new Content Sources you have to first push the bundle. There is an interim time when Resolvers are broken during which you are manually diffing the Resolver setup.
If, however, it was possible to push a Content Source change with the Resolver changes (that is, if Resolvers were in encoded in source control and could be deployed with bundles) then the temporarily broken website issue could be resolved. It'd also make tracking down these sort of issues easier– one could go to .git and see what diff caused the breakage.
Resolvers break every time that someone edits a Content Source. In production. There is no way to know if a Content Source change will break the Resolver until it breaks. You can't even deploy a change to a Content Source without breaking your website temporarily.
That's a bug.
We have had edge cases like trailing slashes that are handled differently depending on the environment that lead to undesirable behavior. Other times there was an update to our URL structure.
Either way, knowing which resolver config (across all our environments) is the most up to date one is very important and having a changelog would be helpful.
More generally, problems can also arise when a new bundle is launched to production - there's an initial de-sync between the bundle (with the latest code) and all the UI-managed metadata (which is now outdated) including resolvers, but also site configuration, Ellipsis/Composer config (esp. for Power-ups), PageBuilder pages, templates, and their related configurations.
Having some form of version control (whether it's integrated in the Git repo used for bundles or something that's all managed through the UI and done in the background) would be extremely valuable for ensuring smooth deploys and ongoing stability.
Resolvers are closely tied to the ability to create and manage Templates, which is an action taken in the UI. We would need to preserve the ability to create and manage Resolvers in the UI to continue to support Template creation.
You mentioned version control for regressions - what kinds of bugs have you run into and can you provide several use cases?