-
New Feature
-
Resolution: Won't Do
-
Major
-
Jenkins 1.615
Gitlab hook plugin: 1.4.0
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:
- Commit to master
branch of repo FOO - Jenkins/plugin recieves notification and creates project named FOO. Expected name should be FOO_master
- 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
- Commit to develop branch of repo FOO
- 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.
[JENKINS-28973] naming autogenerated project does not postfix with branchname on first creation
| Description |
Original:
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: # Commit to {code:java} master {code} branch of repo FOO # Jenkins/plugin recieves notification and creates project named FOO. Expected name should be FOO_master # 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 # Commit to develop branch of repo FOO # Jenkins/Plugin recieves notification and creates project named FOO_develop as expected. According to log the project FOO_develop is based on project FOO |
New:
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: # Commit to *master* branch of repo FOO # Jenkins/plugin recieves notification and creates project named *FOO*. Expected name should be *FOO_master* # 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 # Commit to develop branch of repo FOO # Jenkins/Plugin recieves notification and creates project named *FOO_develop as expected*. According to log the project FOO_develop is based on project FOO |
| Description |
Original:
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: # Commit to *master* branch of repo FOO # Jenkins/plugin recieves notification and creates project named *FOO*. Expected name should be *FOO_master* # 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 # Commit to develop branch of repo FOO # Jenkins/Plugin recieves notification and creates project named *FOO_develop as expected*. According to log the project FOO_develop is based on project FOO |
New:
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: # Commit to *master* branch of repo FOO # Jenkins/plugin recieves notification and creates project named *FOO*. Expected name should be *FOO_master* # 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 # Commit to develop branch of repo FOO # 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. |
| Resolution | New: Not A Defect [ 7 ] | |
| Status | Original: Open [ 1 ] | New: Resolved [ 5 ] |
| Issue Type | Original: Bug [ 1 ] | New: New Feature [ 2 ] |
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.)
| Resolution | Original: Not A Defect [ 7 ] | |
| Status | Original: Resolved [ 5 ] | New: Reopened [ 4 ] |
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/
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
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.