We want to move the webservice features to be hosted inside the jobs-api itself.

Started a design document to bootstrap the list of options, will move here once the discussion stabilizes

• https://docs.google.com/document/d/1m-G_URVxKmCtuyvIE-X-7jyDU1IFmgbT3GIR6EhgjI0/edit?tab=t.0 (ask for edit permission if you want to edit, can't give it directly due to technical setup).

High level tasks:

Things that needs to be done

(merged with T388092: allow exposing continuous jobs to the internet via `toolname.toolforge.org`, just like webservice)

• Change image-config to have a webservice-defaults entry in each image (see https://gitlab.wikimedia.org/repos/cloud/toolforge/image-config/-/merge_requests/18#note_196349), with the overrides for that image (replaces the extras and wstype in the web variant config)
• Implement this feature in jobs-api
  • Adding a new API model to handle validation LegacyWebservice
  • It has to override any defaults with the default from image-config (and flag them as user-provided, so when returning the DefinedContinuousJob the values are there).
  • Configure httproutes (under / on <tool>.toolforge.org), services, ensure nothing conflicts with the webservice
  • We may have to make some validation changes to webservice itself, to verify that the domain name toolname.toolforge.org is not in use by jobs-api
  • Make sure that the API docs are clear and flag it as deprecated pointing to the continuous job + ingress instead
• Implement the feature in jobs-cli
  • Using argument --publish
• Testing (especially ensuring this doesn't affect how the webservice works)
• Cloud announce/toolforge changelog