The pregitflow project changed the dataset paths of shipped releases from
http://linux-package-mirror.delphix.com/release/ to http://linux-package-mirror.delphix.com/releases/.
This caused a regression because the linux-pkg repo used the `DEFAULT_GIT_BRANCH` as the path of the dataset to fetch from because they were both the same `release/A.B.C.D` but now they have changed. The "branches" (tags, really) are still following the old scheme `release/A.B.C.D` but the datasets are not under `releases/A.B.C.D`.
So, I modified the jenkins job in https://github.com/delphix/devops-gate/pull/802 to pass the new scheme to linux-pkg,
and it worked for most build-pkg jobs of shipped releases until now when I tried to ship a hotfix of the azure kernel package: http://selfservice.jenkins.delphix.com/job/linux-pkg/job/custom/job/build-package/job/custom/221/console
```
00:04:06.912 Running: [token passed] git fetch https://github.com/delphix/zfs.git --no-tags +releases/7.0.0.0:repo-HEAD --depth=1
00:04:07.251 fatal: couldn't find remote ref releases/7.0.0.0
```
The reason why this has likely only come to light right now is because the `virtualization` package does not have dependencies that needed to be rebuilt.
```
00:00:23.132 Final build list after applying BUILD_POLICY and REBUILD_DEPENDENCIES policies:
00:00:23.132 [virtualization]
```
vs in my case:
```
00:00:44.823 Final list of packages to build:
00:00:44.823 [linux-kernel-azure, connstat, delphix-kernel, zfs]
```
Solution
The fix should be to revert the jenkins job to continue using the true branch scheme `release/A.B.C.D` instead of `releases/A.B.C.D` and modify linux-pkg to not conflate the value to fetch packages from the mirror.
Devops-gate review: https://github.com/delphix/devops-gate/pull/1271
Testing Done
http://selfservice.jenkins-palashgandhi.dcol2.delphix.com/job/hotfix-build/14/console
Build a virtualization HF: http://selfservice.jenkins-palashgandhi.dcol2.delphix.com/job/hotfix-build/16/console
The pregitflow project changed the dataset paths of shipped releases from http://linux-package-mirror.delphix.com/release/ to http://linux-package-mirror.delphix.com/releases/. This caused a regression because the linux-pkg repo used the `DEFAULT_GIT_BRANCH` as the path of the dataset to fetch from because they were both the same `release/A.B.C.D` but now they have changed. The "branches" (tags, really) are still following the old scheme `release/A.B.C.D` but the datasets are not under `releases/A.B.C.D`. So, I modified the jenkins job in https://github.com/delphix/devops-gate/pull/802 to pass the new scheme to linux-pkg, and it worked for most build-pkg jobs of shipped releases until now when I tried to ship a hotfix of the azure kernel package: http://selfservice.jenkins.delphix.com/job/linux-pkg/job/custom/job/build-package/job/custom/221/console ``` 00:04:06.912 Running: [token passed] git fetch https://github.com/delphix/zfs.git --no-tags +releases/7.0.0.0:repo-HEAD --depth=1 00:04:07.251 fatal: couldn't find remote ref releases/7.0.0.0 ``` The reason why this has likely only come to light right now is because the `virtualization` package does not have dependencies that needed to be rebuilt. ``` 00:00:23.132 Final build list after applying BUILD_POLICY and REBUILD_DEPENDENCIES policies: 00:00:23.132 [virtualization] ``` vs in my case: ``` 00:00:44.823 Final list of packages to build: 00:00:44.823 [linux-kernel-azure, connstat, delphix-kernel, zfs] ```Problem
The fix should be to revert the jenkins job to continue using the true branch scheme `release/A.B.C.D` instead of `releases/A.B.C.D` and modify linux-pkg to not conflate the value to fetch packages from the mirror. Devops-gate review: https://github.com/delphix/devops-gate/pull/1271Solution
http://selfservice.jenkins-palashgandhi.dcol2.delphix.com/job/hotfix-build/14/console Build a virtualization HF: http://selfservice.jenkins-palashgandhi.dcol2.delphix.com/job/hotfix-build/16/consoleTesting Done