Build: don't run default steps if no sphinx or mkdocs

[humitos]

This PR modifies the build to not run default commands when the user doesn't specify sphinx or mkdocs configs in the YAML file.

This allows to use the following YAML file to build with Docusaurus, for example:

version: 2

build:
  os: ubuntu-24.04
  tools:
    nodejs: "22"
  jobs:
    install:
      - cd docs/ && npm install
    build:
      html:
        - cd docs/ && npm run build
    post_build:
      - mkdir --parents $READTHEDOCS_OUTPUT/html/
      - cp --recursive docs/build/* $READTHEDOCS_OUTPUT/html/

This is the structure I've been wanting to have to allow any type of doctool to work in our platform following the build.jobs pattern.

The code deployed in production doesn't allow this because it runs automatically create_environment, install_core_dependencies and install_requirements even if the project is not using Python --which is incorrect. It fails with the generic error: "Unknown problem. There was a problem with Read the Docs while building your documentation"

• https://app.readthedocs.org/projects/test-builds/builds/26425680/
• https://read-the-docs.sentry.io/issues/4458662274/

This PR detects if the user is defining sphinx or mkdocs and if it's not, it doesn't run those jobs and leave the user to handle the build workflow completely.

• Related Npm install support #11216
• Related Build: implement build.jobs.create_environment and build.jobs.install #11551

[humitos]

Note this may not be the best code implementation and I'm happy to adapt it. However, I wanted to have something working to show the use case I've been wanting to have in our platform and show a real example.

We are doing plenty of magic in our config file (eg. auto populating fields that the user didn't declare) and this code may need some refactor/adaption to be sure we are not breaking patterns that were working previously.

[ericholscher]

Conceptually this makes sense to me. I'm not 100% sure the best options for implementation, so tagging @stsewd on this as well. I think this is an obvious next step for the build.jobs.build logic, and makes sense to keep trying to make it support more generic logic.

[agjohnson]

Agreed on avoiding these default steps.

Note, there are some projects in the middle here that don't have a sphinx key but are using Sphinx builder. So, maybe we could use a middle step here too, like if there are build jobs and no sphinx key, we don't do the default steps?