Skip reindex step during tutor deployment

Site Operators Tutor Help
1

Is there an advisable way to skip reindexing all courses when deploying with Tutor?

Our site does not use the native content search functionality, and yet each deployment spends over 10 minutes running reindex_studio and reindex_course with little return benefit. Is there an existing feature flag or setting that would allow us to skip these steps?

2

Hi @Jeff_Cohen
I don’t have a solution for you unfortunately, but just out of curiosity, how many courses does your platform have? Granted mine is fairly small (40 courses at the moment) but it takes approx 3-5 seconds to perform the reindexing for me…

3

You can edit that file in your site-packages folder, comment out the reindex line, and run tutor config save. However, I suggest running it after you’ve run the tutor launch command.

4

@joel.edwards We currently have around 650 courses which vary in size. The largest course has around 270 units. We have around 80 courses with over 50 units, and the rest are somewhere smaller than that.

5

Here’s my hacky solution in a custom python plugin:

@hooks.Actions.DO_JOB.add()
def _override_cms_task(job_name: str, *args, **kwargs):
    if job_name == "init":
        env_root = get_current_context().obj.root
        # Remove the native CMS init task
        cms_context = hooks.Contexts.app("cms")
        hooks.Filters.CLI_DO_INIT_TASKS.clear(cms_context.name)

        # Then replace it with our custom version that excludes course indexing
        with open(
            pathjoin(env_root, "plugins", "customcairn", "jobs", "init", "cms.sh"),
            encoding="utf-8",
        ) as fi:
            task = fi.read()
        with cms_context.enter():
            hooks.Filters.CLI_DO_INIT_TASKS.add_item(("cms", task))

        fmt.echo_info(f"Overrode CMS task for job: {job_name}")

Meanwhile, I created a custom version of cms.sh that almost exactly matches the native tutor version, but excludes the final two commands for reindex_studio and reindex_course.

This approach seems to be working fine for now and has trimmed significant time off my deployments. However, it’s going to be sensitive to maintain it with each release to make sure that cms.sh gets updated to stay aligned with the native implementation over time. This also assumes that there is only one cms task which is getting replaced one-for-one. If a separate plugin were to add additional cms tasks to the init queue, they would get wiped out by this implementation.

I’m open to other suggestions for how to achieve this outcome, but at least this works for now.

1 Like
6

@Jeff_Cohen Can you please comment on this issue? cms-job taking too long to finish · Issue #1197 · overhangio/tutor · GitHub