"Run Pipeline" UI fails to render input form when default inputs result in an empty pipeline (validation deadlock)

Description:

Summary When using spec:inputs in .gitlab-ci.yml, if the default values of the inputs result in a pipeline configuration with no jobs (e.g., via conditional include), the "Run Pipeline" page throws a validation error immediately ("jobs spec config should implement...").

Crucially, this error prevents the Input Form from rendering. This creates a deadlock: the user cannot change the input value to a valid state (which would generate jobs) because the UI crashes on the default invalid state.

Steps to reproduce

1. Create a new project (or use an existing one).
2. Create a file named child-pipeline.yml with the following content:

hello_job:
  script: echo "Hello World"

3. Create a .gitlab-ci.yml file with the following content (using spec:inputs and conditional include):

spec:
  inputs:
    enable_feature:
      description: "Enable the feature pipeline"
      default: "false"
      options:
        - "true"
        - "false"

include:
  - local: 'child-pipeline.yml'
    rules:
      # Include only if the input is explicitly set to true
      - if: '$enable_feature == "true"'

4. Navigate to Build > Pipelines and click "Run pipeline".

Expected behavior The "Run pipeline" page should load successfully and display the Form UI for spec:inputs. I should be able to change enable_feature from false (default) to true and then submit the pipeline.

Actual behavior The page displays a red error banner:

This GitLab CI configuration is invalid: jobs spec config should implement the script:, run:, or trigger: keyword.

The form for spec:inputs is not displayed, making it impossible to change the variable to true via the UI.

Possible Fix The "Run Pipeline" view should render the spec:inputs form even if the default pipeline configuration evaluates to an empty set of jobs.

Workaround Adding a dummy "no-op" job to the main .gitlab-ci.yml file prevents the error, as the pipeline is no longer empty by default.

dummy_job:
  stage: .pre
  script: echo "Pipeline initialized"
  rules:
    - when: always

Drawback of this workaround: This approach is suboptimal because it forces the execution of unnecessary "dummy" jobs. This pollutes the project's pipeline history with empty runs whenever a user opens the pipeline page or triggers it with defaults. It confuses users (who see "passed" pipelines that did nothing) and consumes unnecessary runner overhead just to allow the UI form to render.