Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-66187

No changes detected for standalone job

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Open (View Workflow)
    • Priority: Minor
    • Resolution: Unresolved
    • Component/s: bitbucket-plugin, core
    • Labels:
      None
    • Environment:
      Jenkins version 2.289.1, mac, chrome, bitbucket 1.1.29
    • Similar Issues:

      Description

      I have a standalone job that runs unit tests that I want to run against any branch that is updated.  The current situation is that it will only build automatically when the primary develop branch is updated, but I also need it to run against the release, bug fix, and feature branches. There are also branches that fit no expected naming schema. The repo I'm running this against is a mono repo and we only use one specific folder path for this build, so I have it successfully ignoring everything but that path. (If I could get this to build against ANY branch, I would call it a win)

      I have build when a change is pushed to Bitbucket and poll scm every 5 minutes currently set up. Repo branch is a parameter that gets inserted into the branch specifier field and lightweight checkout is selected.

       

      Things that I've tried that haven't worked..

      • Calculating changelog against a specific branch (tried develop and origin as the name of repo and ${REPO_BRANCH} as the name of branch)
      • Changing the branch specifier
        • remotes/origin/{REPO_BRANCH}
        • refs/head/{REPO_BRANCH}
        • origin/*/{REPO_BRANCH}
        • None of these patterns trigger a build.. all return no changes found.
      • Changing the default REPO_BRANCH to blank and **
        • It's usually set to the default develop branch

       

      The closest I got to this working was when I set the parameter to ** and it recognized 153 branches in our rather large mono repo.. but it somehow still found no changes even though I just created a branch, pushed changes, and made a PR to hopefully trigger something.  Could someone help me with this?  I've contacted my company's devops team and they are stumped as well. I feel like this shouldn't be as hard as it is turning out to be.  I'm unsure if I'm hitting a bug in Jenkins or it is because our repo's configuration is so complex.

      If this isn't enough information to assist or diagnosis a potential problem, please let me know and I'll try to get you more information. This is something we would like to implement on several of our builds, but apparently no one has gotten it working.

       

       

        Attachments

          Activity

          Hide
          markewaite Mark Waite added a comment - - edited

          Having a single job that switches between branches is almost always a poor experience for users. They are forced to look inside the console output or in some other location to decide which branch was used for that job. Was build 5 on the develop branch or on the master branch? Did the transition from build 6 to build 7 also include a change of branch?

          I'd create a job per branch so that the users aren't puzzled by the job that changes from one branch to a different branch. That job could be a Pipeline job (first preference) or a Freestyle job.

          Show
          markewaite Mark Waite added a comment - - edited Having a single job that switches between branches is almost always a poor experience for users. They are forced to look inside the console output or in some other location to decide which branch was used for that job. Was build 5 on the develop branch or on the master branch? Did the transition from build 6 to build 7 also include a change of branch? I'd create a job per branch so that the users aren't puzzled by the job that changes from one branch to a different branch. That job could be a Pipeline job (first preference) or a Freestyle job.
          Hide
          aellison Amanda added a comment -

          Mark Waite We modify the build names so that users don't have to dive into each run to see their parameters and when that isn't possible, we output those variables in the slack notifications triggered by each run. You can also use the search bar to query for specific parameters, like branch name, to get a list of the builds ran against a specific branch. We haven't really run into the issue you're describing.

          The repo in question is a mono repo with around 75 active branches, some follow the typical /release, /feature, /bugfix naming convention and some are named after the Jira ticket the commit is connected to. What do you recommend for a repo of this size?

          I'm also curious why your first preference is a pipeline job. I often see people bypass standalone jobs completely, even for simple stuff that could be accomplished in a few lines of shell script, so I was wondering if I was missing something.  

          Show
          aellison Amanda added a comment - Mark Waite  We modify the build names so that users don't have to dive into each run to see their parameters and when that isn't possible, we output those variables in the slack notifications triggered by each run. You can also use the search bar to query for specific parameters, like branch name, to get a list of the builds ran against a specific branch. We haven't really run into the issue you're describing. The repo in question is a mono repo with around 75 active branches, some follow the typical /release, /feature, /bugfix naming convention and some are named after the Jira ticket the commit is connected to. What do you recommend for a repo of this size? I'm also curious why your first preference is a pipeline job. I often see people bypass standalone jobs completely, even for simple stuff that could be accomplished in a few lines of shell script, so I was wondering if I was missing something.  
          Hide
          markewaite Mark Waite added a comment -

          I prefer multibranch Pipeline jobs because they allow me to control the creation, refinement, and deletion of Jenkins jobs from a git repository, with git history to describe the changes. Jobs are created and deleted automatically as I create and remove branches with a Jenkinsfile in the branch. The Jenkinsfile can call the shell script so that users can run the shell script without requiring Jenkins. The Jenkins job definition is then very simple (sh 'my-shell-script') and all the heavy lifting happens inside the shell script.

          Single job per branch seems like it would simplify your job definition so that you don't need to modify the build name.

          I have a large repo that currently has 174 branches and I have a Jenkinsfile in almost every branch in that repository.

          I'm generally not investing effort in the git plugin to make things work better for a single job that switches between branches. That was a technique we used frequently before Jenkins Pipeline and multibranch Pipeline became available. It is a technique that is used less frequently now that multibranch Pipeline is available. I'm not stating that your use case is invalid, only that as a plugin maintainer, I'm not spending effort to improve your use case, while I do spend effort to improve the Pipeline use cases.

          Show
          markewaite Mark Waite added a comment - I prefer multibranch Pipeline jobs because they allow me to control the creation, refinement, and deletion of Jenkins jobs from a git repository, with git history to describe the changes. Jobs are created and deleted automatically as I create and remove branches with a Jenkinsfile in the branch. The Jenkinsfile can call the shell script so that users can run the shell script without requiring Jenkins. The Jenkins job definition is then very simple (sh 'my-shell-script') and all the heavy lifting happens inside the shell script. Single job per branch seems like it would simplify your job definition so that you don't need to modify the build name. I have a large repo that currently has 174 branches and I have a Jenkinsfile in almost every branch in that repository. I'm generally not investing effort in the git plugin to make things work better for a single job that switches between branches. That was a technique we used frequently before Jenkins Pipeline and multibranch Pipeline became available. It is a technique that is used less frequently now that multibranch Pipeline is available. I'm not stating that your use case is invalid, only that as a plugin maintainer, I'm not spending effort to improve your use case, while I do spend effort to improve the Pipeline use cases.

            People

            Assignee:
            Unassigned Unassigned
            Reporter:
            aellison Amanda
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Dates

              Created:
              Updated: