Open Bug 1703115 Opened 1 month ago Updated 1 month ago

Stop using absolute /static/ paths in favor of either /tree/static/ or relative paths

Categories

(Webtools :: Searchfox, task)

task

Tracking

(Not tracked)

People

(Reporter: asuth, Unassigned)

References

Details

Today's breakage (bug 1703077) ended up being a little more extensive because our use of a single /static/ route across all of the different configN configurations acts in opposition to our isolation of the different machine configurations. We should switch to having the static resources for each configuration and tree/repository be specific to that tree/repository by exposing the static resources at /tree/static/, for example /mozilla-central/static/.

Although slightly more complex from an application perspective, it could also be beneficial for us to reference these paths via relative paths like ../../static/blah/ because this could enable UI experimentation by letting us do tricky like having /mozilla-central/ and /fancy-mozilla-central/ serve a different effective UI for the same static HTML page without actually having to do twice the work and without having to dynamically recompute all the paths. (Alternately, I suppose that could be addressed via reverse proxying.)

The flip side to this is that when all the webservers are using the same CSS, we don't need to regenerate the config3 web server for every CSS change, which is nice. I don't have strong feelings either way.

In that case we can also just update the git checkout too.

One other nicety of a change like this is that it could make the rollout of more extensive changes to searchfox a little easier. Specifically, for the structured analysis branch, especially if we go forward with linking as proposed, we run into the issue of the taskcluster jobs for older branches of searchfox potentially not producing what the trunk indexing jobs want and thereby experiencing some level of breakage/degraded functionality. But if we, in effect, let them be totally isolated, we could specify that the config2-4 should continue to use an older "stable" branch of searchfox for indexing until such time as we're able to make sure we've uplifted changes to the older branches (or the changes just get there naturally) or ensured that the we've dealt with or understood and accepted any fallout/drift. (The structured analysis changes themselves I think are fine, but imply removing the existing in-mozsearch XPIDL indexing.)

Logistically: We could presumably have a deployment helper tool that scans the list of existing web-servers, checks their revisions and how far they are from trunk, then determines whether anything has changed that would mandate a re-indexing or if just updating the checkout is sufficient. I guess changes to anything but /static/ or /docs/ would probably want to presume a re-indexing.

You need to log in before you can comment on or make changes to this bug.