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

naming autogenerated project does not postfix with branchname on first creation

    Details

    • Similar Issues:

      Description

      According to documentation an autogenerated project should be named by the repo name and then postfixed with the branch, i.e. REPONAME_BRANCH

      In my testing i have observed that this is not the case the first time a project is created from an unknown repository notification. Then the name of the Jenkins project will match only the gitlab repo name and not prefix the branchname.

      Setup:

      Jenkins 1.615
      Gitlab hook plugin: 1.4.0
      Automatic project creation is ON
      Template based job creation is used and ONLY base project has a value
      gitlabhookpluginsetup

      Scenario:
      Prerequisite.

      Reponame FOO
      Gitlab repo FOO has webhook to jenkins using build_now
      Jenkins does not have a Project relating to repo FOO
      Reproduce:

      1. Commit to master
        branch of repo FOO
      2. Jenkins/plugin recieves notification and creates project named FOO. Expected name should be FOO_master
      3. Commit to master branch of repo FOO again and observe that Jenkins/plugin creates a new project named FOO_master. This is wierd since the Jenkins project FOO relate to the master branch
      4. Commit to develop branch of repo FOO
      5. Jenkins/Plugin recieves notification and creates project named FOO_develop as expected. According to log the project FOO_develop is based on project FOO

      nb.
      The attached image shows the setup of the plugin.

        Attachments

          Activity

          Hide
          javiplx Javier Palacios added a comment -

          I'll check the documentation, but that is the expected behaviour. Although both projects get created automatically, they follow quite different paths. When it receives an unknown branch for a known repository, it uses the existing job as base, but when the notification is for a completely unknown repository, it is created from a template.
          On the first case, there is a configuration flag to select whether the new project is prefixed with the repository name or with the name of the "cloned" project. On the second case only the repository name can be used and no branch name is suffixed because the assumption is that this first push is for the master branch.

          Show
          javiplx Javier Palacios added a comment - I'll check the documentation, but that is the expected behaviour. Although both projects get created automatically, they follow quite different paths. When it receives an unknown branch for a known repository, it uses the existing job as base, but when the notification is for a completely unknown repository, it is created from a template. On the first case, there is a configuration flag to select whether the new project is prefixed with the repository name or with the name of the "cloned" project. On the second case only the repository name can be used and no branch name is suffixed because the assumption is that this first push is for the master branch.
          Hide
          tlogik Thomas Blitz added a comment -

          I think that the 'expected' behaviour is counter intuitive.
          I understand the different paths but the goal should be the same, namely:
          1. Create projects
          2. postfix with branch name, independant of if the repo is unknown or not. Then there is no unnecessary manually work required, as explained below.

          These two goals should always be upheld in all cases.
          We can safely assume that there will always be a branch associated with a commit so the branch name should be postfixed.

          The issue above has the undesired outcome that:
          1. You commit to ex. master for repo FOO, and the plugin creates a new project in Jenkins because the repo is unknown.. The project is named something like FOO in jenkins, even thou the branch is master.
          2. You commit to master of FOO again. The plugin creates a NEW project called: FOO_master which is based on the project FOO. I argue that the first time a project is created it should also be postfixed with the branch since this is the behaviour it will do afterwards on all commits to any branch.
          At least allow it to be a settable property on the plugin.

          The outcome in our env. is that after we commit the first time and the plugin creates the base, non postfixed repo, we then immediately commit again, allow the plugin to create yet another project that has the branch postfix, and then we have to delete the original non postfixed project - manually, thus automation fails in this case.

          I will change the type from bug to feature request, since i can understand from you that the the current behaviour is expected, but at least it think it should change.
          I'll attempt to fix it as described above and then close the issue at that point, even thou my Ruby skills = zero :-/ (and as far as i remember the plugin is written in ruby.)

          Show
          tlogik Thomas Blitz added a comment - I think that the 'expected' behaviour is counter intuitive. I understand the different paths but the goal should be the same, namely: 1. Create projects 2. postfix with branch name, independant of if the repo is unknown or not. Then there is no unnecessary manually work required, as explained below. These two goals should always be upheld in all cases. We can safely assume that there will always be a branch associated with a commit so the branch name should be postfixed. The issue above has the undesired outcome that: 1. You commit to ex. master for repo FOO, and the plugin creates a new project in Jenkins because the repo is unknown.. The project is named something like FOO in jenkins, even thou the branch is master. 2. You commit to master of FOO again. The plugin creates a NEW project called: FOO_master which is based on the project FOO. I argue that the first time a project is created it should also be postfixed with the branch since this is the behaviour it will do afterwards on all commits to any branch. At least allow it to be a settable property on the plugin. The outcome in our env. is that after we commit the first time and the plugin creates the base, non postfixed repo, we then immediately commit again, allow the plugin to create yet another project that has the branch postfix, and then we have to delete the original non postfixed project - manually, thus automation fails in this case. I will change the type from bug to feature request, since i can understand from you that the the current behaviour is expected, but at least it think it should change. I'll attempt to fix it as described above and then close the issue at that point, even thou my Ruby skills = zero :-/ (and as far as i remember the plugin is written in ruby.)
          Hide
          javiplx Javier Palacios added a comment -

          Yes, it's written in ruby (or jruby, which is even a bit worse ...)

          1. You commit to ex. master for repo FOO, and the plugin creates a new project in Jenkins because the repo is unknown.. The project is named something like FOO in jenkins, even thou the branch is master.
          2. You commit to master of FOO again. The plugin creates a NEW project called: FOO_master which is based on the project FOO. I argue that the first time a project is created it should also be postfixed with the branch since this is the behaviour it will do afterwards on all commits to any branch.

          If that is the behaviour you see, then it is a real bug. Point 2 should happen, because the plugin should discover that there is a project already tracking master branch, and will schedule a build for it instead of creating a new one. And if it happens, it should happen also if project name is postfixed, because it reads branchspec from git configuration, not the project name. And in that case, you will end with FOO_master_master_master after a while.

          I saw that behaviour at some point in the past, although I believe only in development version. In any case, I'm publishing a new release (1.4.1.1) with a few fixes done long time ago. Please try it and tell me if this issue still applies. The new release will take some time to appear on update center, but you can get it the latest snapshot from http://maven.jenkins-ci.org/content/repositories/snapshots/org/jenkins-ci/ruby-plugins/gitlab-hook/1.4.1-SNAPSHOT/

          Show
          javiplx Javier Palacios added a comment - Yes, it's written in ruby (or jruby, which is even a bit worse ...) 1. You commit to ex. master for repo FOO, and the plugin creates a new project in Jenkins because the repo is unknown.. The project is named something like FOO in jenkins, even thou the branch is master. 2. You commit to master of FOO again. The plugin creates a NEW project called: FOO_master which is based on the project FOO. I argue that the first time a project is created it should also be postfixed with the branch since this is the behaviour it will do afterwards on all commits to any branch. If that is the behaviour you see, then it is a real bug. Point 2 should happen, because the plugin should discover that there is a project already tracking master branch, and will schedule a build for it instead of creating a new one. And if it happens, it should happen also if project name is postfixed, because it reads branchspec from git configuration, not the project name. And in that case, you will end with FOO_master_master_master after a while. I saw that behaviour at some point in the past, although I believe only in development version. In any case, I'm publishing a new release (1.4.1.1) with a few fixes done long time ago. Please try it and tell me if this issue still applies. The new release will take some time to appear on update center, but you can get it the latest snapshot from http://maven.jenkins-ci.org/content/repositories/snapshots/org/jenkins-ci/ruby-plugins/gitlab-hook/1.4.1-SNAPSHOT/
          Hide
          tlogik Thomas Blitz added a comment -

          No, you misunderstand me.
          Let be clarify.

          Scenario 1. Repo FOO is unknown to the plugin.
          Behaviour.
          On commit to branch ex. master the plugin recieves the commit via webhook. Then it creates a Jenkins project named FOO. No postfix of branch master (as i argue it should)

          Scenario 2. Repo FOO has been thru Scenario 1 and that is the current state.
          Behaviour.
          On second commit to master branch of FOO the plugin recieves the commit via webhook.
          Then it creates a new project named: FOO_master based on the previous project named FOO.
          This is expected and all is ok, because the plugin bases the new project on a previous one.

          Scenario 3. Repo FOO recieves a third commit to master.
          Behaviour.
          The plugin does not create a new project named FOO_master_master but simply triggers FOO_master.
          This is the expected behaviour.

          Scenario 4. Repo FOO recieves commit to ex. develop branch.
          Behaviour:
          The plugin creates a new project named: FOO_develop and bases it on a previous project that has the basename of FOO.
          This is expected.

          So i simply want it to start out by postfixing the branchname even when the Repo is unknown in jenkins.

          I hope that clarifies any misunderstandings

          ps. If you are the developer on this plugin i have an idea i would like to discuss with you, if you have 5 minutes for that maybe skype text chat?

          Regards
          Thomas

          Show
          tlogik Thomas Blitz added a comment - No, you misunderstand me. Let be clarify. Scenario 1. Repo FOO is unknown to the plugin. Behaviour. On commit to branch ex. master the plugin recieves the commit via webhook. Then it creates a Jenkins project named FOO. No postfix of branch master (as i argue it should) Scenario 2. Repo FOO has been thru Scenario 1 and that is the current state. Behaviour. On second commit to master branch of FOO the plugin recieves the commit via webhook. Then it creates a new project named: FOO_master based on the previous project named FOO. This is expected and all is ok, because the plugin bases the new project on a previous one. Scenario 3. Repo FOO recieves a third commit to master. Behaviour. The plugin does not create a new project named FOO_master_master but simply triggers FOO_master. This is the expected behaviour. Scenario 4. Repo FOO recieves commit to ex. develop branch. Behaviour: The plugin creates a new project named: FOO_develop and bases it on a previous project that has the basename of FOO. This is expected. So i simply want it to start out by postfixing the branchname even when the Repo is unknown in jenkins. I hope that clarifies any misunderstandings ps. If you are the developer on this plugin i have an idea i would like to discuss with you, if you have 5 minutes for that maybe skype text chat? Regards Thomas
          Hide
          javiplx Javier Palacios added a comment -

          Then, scenario 2 hits a bug, which is fixed on release 1.4.1.1. The acceptance tests for template based creation performs these steps successfully

          1. Finds fallback template
          2. Does not create project for tag
          3. Creates project from template
          4. Does nothing for tags
          5. Builds a push to master branch

          and the second push uses the already created project, and does not create a new one.
          Anyway, I'll add an option to postfix the branch name even on template based creation, because it has sense and covers the case where the first push after configuring webhook is not for master branch.

          Show
          javiplx Javier Palacios added a comment - Then, scenario 2 hits a bug, which is fixed on release 1.4.1.1. The acceptance tests for template based creation performs these steps successfully Finds fallback template Does not create project for tag Creates project from template Does nothing for tags Builds a push to master branch and the second push uses the already created project, and does not create a new one. Anyway, I'll add an option to postfix the branch name even on template based creation, because it has sense and covers the case where the first push after configuring webhook is not for master branch.
          Hide
          javiplx Javier Palacios added a comment -

          And yes, I'm current developer of plugin. I don't usually use skype, but If your timezone is compatible with something like 20:00 GMT, we can arrange a chat.

          Show
          javiplx Javier Palacios added a comment - And yes, I'm current developer of plugin. I don't usually use skype, but If your timezone is compatible with something like 20:00 GMT, we can arrange a chat.
          Hide
          tlogik Thomas Blitz added a comment -

          Great news about the postfix on initial commit. I am very happy and it is going to save us many hours and irritation.

          Then to my idea that i would like to quickly hear your thoughts about.

          Scenario.
          When we f.ex. delete branches the plugin does delete the project in Jenkins, and that is nice.
          WE do however also have a number of subsystems, with API's, that also needs information about the delete.
          So far we handle this manually and do the actions required by hand.
          We could however automate it with scripts.

          So the idea is to be able to trigger a script upon a delete in gitlab via the plugin.
          Simplest scenario is that on every commit the gitlab plugin will allow a kind of a chain where it will push the commit information to some kind of script runner. Something very generic.

          I can argue that allowing the gitlab plugin to implement this feature could be wrong. Should this really be there.
          I could argue that maybe i should make a new plugin, that also get triggered via a webhook in gitlab and then it can run scripts.

          So a quick yes or no from you
          Do you think that the gitlab plugin could/should have the ability to trigger some kind of script mechanism or should it be in a separate new plugin.

          The main reason for choosing the gitlab plugin would be the infrastructure that is already present in you code for webhook handling and processing of the webhook information.

          Show
          tlogik Thomas Blitz added a comment - Great news about the postfix on initial commit. I am very happy and it is going to save us many hours and irritation. Then to my idea that i would like to quickly hear your thoughts about. Scenario. When we f.ex. delete branches the plugin does delete the project in Jenkins, and that is nice. WE do however also have a number of subsystems, with API's, that also needs information about the delete. So far we handle this manually and do the actions required by hand. We could however automate it with scripts. So the idea is to be able to trigger a script upon a delete in gitlab via the plugin. Simplest scenario is that on every commit the gitlab plugin will allow a kind of a chain where it will push the commit information to some kind of script runner. Something very generic. I can argue that allowing the gitlab plugin to implement this feature could be wrong. Should this really be there. I could argue that maybe i should make a new plugin, that also get triggered via a webhook in gitlab and then it can run scripts. So a quick yes or no from you Do you think that the gitlab plugin could/should have the ability to trigger some kind of script mechanism or should it be in a separate new plugin. The main reason for choosing the gitlab plugin would be the infrastructure that is already present in you code for webhook handling and processing of the webhook information.
          Hide
          javiplx Javier Palacios added a comment -

          About your idea, my current thinking is that it could be a work for another plugin. On one side, whichever 'script' receives the hook should be able to hande a few kins (standard push, tag, branch deletion), which becomes a bit complex. And on another side, there is the 'triggering' issue, because the matching project is selected based on the git url & branch, so the script should get executed on every push. And, finally, there is little control about what the 'script' does, and I don't want the plugin to create something it can't delete (and oppositely only delete things that it created before).

          Maybe I don't see clearly your use case, but the closer ones I see are pipeline alike , could be accomplished (maybe not easily) by chaining standard jenkins jobs or with plugins like flow dsl one. If you can live by triggering always the same job for a given repo (which is your 'script'), then there is a feature I'm working on might be useful to you (have a look to JENKINS-29317).

          If you are able to elaborate a bit more your use case, I will thing a bit more about this.

          Show
          javiplx Javier Palacios added a comment - About your idea, my current thinking is that it could be a work for another plugin. On one side, whichever 'script' receives the hook should be able to hande a few kins (standard push, tag, branch deletion), which becomes a bit complex. And on another side, there is the 'triggering' issue, because the matching project is selected based on the git url & branch, so the script should get executed on every push. And, finally, there is little control about what the 'script' does, and I don't want the plugin to create something it can't delete (and oppositely only delete things that it created before). Maybe I don't see clearly your use case, but the closer ones I see are pipeline alike , could be accomplished (maybe not easily) by chaining standard jenkins jobs or with plugins like flow dsl one. If you can live by triggering always the same job for a given repo (which is your 'script'), then there is a feature I'm working on might be useful to you (have a look to JENKINS-29317 ). If you are able to elaborate a bit more your use case, I will thing a bit more about this.

            People

            • Assignee:
              javiplx Javier Palacios
              Reporter:
              tlogik Thomas Blitz
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: