Minor issues when branching an existing package twice in the same repo.

[simotek]

Issue/Feature description

If you "Branch existing package" twice in one repo with the same source package but different branched names the second time it will tell you that you have already branched the existing package and will take you to the previously branched package, although branching the second package will work

Expected result

Go to the new package with no error

How to Reproduce

1. Take any repository home:simotek:patterns (IBS) for example, that repository contains a single package called "patterns-base"
2. From the Web UI go to the home:simotek:patterns repo from there "Branch existing package" using "home:simotek:patterns/patterns-base" as the source and "patterns-enhanced-base" as the destination package.
3. This will work as expected.
4. Repeat step 2, this time creating "patterns-gnome-basic" from patterns base.
5. This time notice you get taken to the page for home:simotek:patterns/patterns-enhanced-base rather then patterns-gnome-basic and you will be shown a error about the package already being branched.
6. You can then go back to the home:simotek:patterns repo and see that despite the error the new package was created.

Further information

• build.suse.de

[jimklimov]

Using an older (late 2015 based) on premise deployment, we have it worse :)

As originally posted on IRC :

Got down the pit of looking why the second+ branches of an original package in the same repo are almost made but unusable (trying to implement my usecase of one preinstallimage recipe with many tweaked instances, made by branch + topadd tags in the _link file - with PR #4095 in place). The effect is that directories are created and populated, database entries are made - and then deleted. Backend sees the repo, frontend says it does not exist even though it is reported in e.g. failed builds list.

After a trip through shell, perl, ruby, sql and a lot of logs I know a lot more ;) Specifically, and only from logs and instrumentation debugs I peppered the scripts with, I now know that there is this branch_package.rb with this DoubleBranchPackageError exception which is thrown unless a "force" parameter is passed. Did not find a way to pass it though.

So it makes sense to both have some protection from stupid things and a way to do them... but WHY NOT PASS THE ERROR TO UI? Would've saved a couple of days, almost literally.

In the end, a local on-premise workaround (maybe wrong, YMMV, be careful when shooting yourself in the foot) was to disable the call a bit higher up in the stack:

--- /srv/www/obs/api/app/helpers/branch_package.rb.orig 2015-11-09 12:09:20.000000000 +0000
+++ /srv/www/obs/api/app/helpers/branch_package.rb      2017-11-03 15:13:50.654145748 +0000
@@ -437,7 +438,9 @@ def extend_packages_to_link(p)
       end
       unless found
         logger.debug "found local linked package in project #{p[:package].project.name}/#{ap.name}, adding it as well, pointing it to #{p[:package].name} for #{target_package}"
-        @packages.push({ base_project: p[:base_project], link_target_project: p[:link_target_project], link_target_package: p[:package].name, package: ap, target_package: target_package, local_link: 1 })
+### Note: TEMPORARILY comment this away and `systemctl restart httpd` to allow
+### many clones of same original package to exist in same target project
+###        @packages.push({ base_project: p[:base_project], link_target_project: p[:link_target_project], link_target_package: p[:package].name, package: ap, target_package: target_package, local_link: 1 })
       end
     end
   end