I ended up with a workaround based on Hannes' answer. It doesn't do exactly what i want, but close enough.

Solution

I couldn't just add a $target variable to my pipeline, it didn't seem to take the updated value from earlier jobs. Instead, i found the dotenv feature of gitlab CI which allowed me to pass the variable to a later script.

I also scrapped the dbg2release job, it's now part of the debug job.

I now have 2 stages: target which has optional manual jobs for picking "debug"(+dbg2release) or "release", and package which has a manual job "package" to publish the package using the configuration which was selected in the previous stage.

It still has annoyances:

• Users can run the "package" job even if they didn't pick a target.

• Users have to start 2 manual jobs

• Users can start both the "debug" and "release" jobs. In that case, the first one to run is ignored.

Code

stages:
  - target
  - package

debug:
  stage: target
  rules:
    - if: '$CI_COMMIT_BRANCH == "develop" && $CI_PIPELINE_SOURCE == "push"
      when: manual
      allow_failure: true
  before_script:
    - []
  after_script:
    - []
  script:
    - echo "TARGET=DEBUG" > target.env
  artifacts:
    reports:
      dotenv: target.env
  
release:
  stage: target
  rules:
    - if: '$CI_COMMIT_BRANCH == "develop" && $CI_PIPELINE_SOURCE == "push"
      when: manual
      allow_failure: true
  before_script:
    - []
  after_script:
    - []
  script:
    - echo "TARGET=RELEASE" > target.env
  artifacts:
    reports:
      dotenv: target.env

package:
  stage: package
  rules:
    - if: '$CI_COMMIT_BRANCH == "develop" && $CI_PIPELINE_SOURCE == "push"
      when: manual
      allow_failure: false
  script:
    - echo $TARGET
    - do things

Other possibility

I could have just added a job variable to the "package" job, and have users enter the variable value manually when running it. Gitlab's UI for doing that is a bit cumbersome and hidden, so i really wanted to avoid it.