Is this specific to Declarative Pipelines, i.e. in the style you've written above, starting with pipeline {?

Just wondering whether this should be reassigned to the pipeline-model-definition component.

Apologies for the delayed reply, it's been unexpectedly busy at work. Unfortunately, I don't actually know how to write a non-declarative pipeline script, certainly not one that's parameterized, and I've had a hard time trying to find or work out such a script.

Edit: Looking at https://jenkins.io/doc/book/pipeline/syntax/#parameters it claims 

which would seem to preclude using it outside of `pipeline {`? If not, certainly I can't discern any more, alas.

So...this brings up a good question! The root cause here is that job parameters, triggers and other misc job properties are all set in Pipeline (including Declarative, albeit behind the scenes) with the properties step...which overwrites whatever was previously in the job properties/triggers/parameters. So if you have parameters in your Declarative Pipeline but not triggers, your triggers are always going to get wiped out. The quiet period and remote trigger bit are technically not part of the triggers which is why they stay set. Is weird, I know.

So a workaround for this for you would be to use this as your Jenkinsfile:

pipeline {
    agent any
    parameters {
       string(name: 'requested', defaultValue: 'all', description: 'Which stages should be run?')
    }
    triggers {
        cron('@daily')
        pollSCM('@hourly')
        githubPush()
        upstream(threshold: hudson.model.Result.SUCCESS, upstreamProjects: "some-project,some-other-project")
    }
    stages {
       stage('stage1') {
          steps {
             echo 'Running stage 1'
          }
       }
    }
 }

I'm not 100% sure upstream will work right - it should but I honestly can't remember for sure. But the other three certainly will.

The question this all raises is whether Declarative should allow the UI-configured job properties/parameters/triggers to persist if they're not explicitly overridden. I'm not sure yet, which is why I'm leaving this open. =)

Fair enough! Well for my part at least, I can confirm adding a triggers{} section solved the problem, so many thanks

Ok, been thinking on this and I think we have to go with overwriting properties/triggers/parameters if they're not explicitly set in the Jenkinsfile. There's no way I can figure out to tell the difference between a property/trigger/parameter defined in the UI and one defined in the previous version of the Jenkinsfile but not in the current one, and we should definitely be removing anything in the latter scenario.

It makes no sense to have both UI config and Jenkinsfile config is they fight and can't get along. 

Ideally it would error or warn if the UI properties/triggers are "set" and Jenkinsfile is also "set". Or else remove it from the UI. Or the Jenkinsfile. as it is - not very nice. 

Bulk closing resolved issues.