Bug #5686
closedttcn3-hnbgw-test isn't working properly
100%
Description
Wrong commit checked out¶
Neels noted that ttcn3-hnbgw-test had been using the wrong docker-playground.git commit 395cdbb41 instead of current HEAD of master 85f0b31. This happened over several days now.
As I understand, this happened:- Neels tested with branch neels/hnbgw-pfcp that had 85f0b31 as HEAD
- This commit was merged into master: https://gerrit.osmocom.org/c/docker-playground/+/29339
- jenkin's git cache got confused when building with branch master again and kept checking out the previous commit 395cdbb41
Wiping the workspace didn't fix it. I also ssh'd into the node and verified that it really deletes the entire workspace, it doesn't leave a .git directory behind.
Apparently git repositories get cached on the jenkins master and we could delete it there (https://stackoverflow.com/a/47185763), I didn't try that.
What helped was explicitly building with 85f0b311f983254a74b8d532abc8ac525df1e9df (set it as BRANCH here: https://jenkins.osmocom.org/jenkins/job/ttcn3-hnbgw-test/build). Then it used that commit, and when building again with the default of "*/master", it picks this proper commit now instead of the previous one. (I also looked if "*/master" could match another branch, but we don't have another in there that ends in master.)
osmo-hnbgw doesn't build¶
So now the proper docker-playground.git commit is getting checked out. But osmo-hnbgw doesn't build:
https://jenkins.osmocom.org/jenkins/job/ttcn3-hnbgw-test/229/console
hnbgw.c:255:6: warning: implicit declaration of function 'msgb_sctp_msg_flags'; did you mean 'msgb_sctp_stream'? [-Wimplicit-function-declaration] 255 | if (msgb_sctp_msg_flags(msg) & OSMO_STREAM_SCTP_MSG_FLAGS_NOTIFICATION) { | ^~~~~~~~~~~~~~~~~~~ | msgb_sctp_stream hnbgw.c:255:33: error: 'OSMO_STREAM_SCTP_MSG_FLAGS_NOTIFICATION' undeclared (first use in this function) 255 | if (msgb_sctp_msg_flags(msg) & OSMO_STREAM_SCTP_MSG_FLAGS_NOTIFICATION) { | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
neels: you are more familiar with the code, passing to you.
Updated by neels over 1 year ago
The build failure happens because msgb_sctp_msg_flags() is newly added to libosmo-netif.
Probably need to wait until the next nightly build happened for libosmo-netif
Updated by neels over 1 year ago
osmith wrote:
Wrong commit checked out¶
Apparently git repositories get cached on the jenkins master
I doubt that.
- jenkin's git cache got confused when building with branch master again and kept checking out the previous commit 395cdbb41
Wiping the workspace didn't fix it. I also ssh'd into the node and verified that it really deletes the entire workspace
Could there be various workspaces on jenkins build slaves that still have a stuck git state?
What helped was explicitly building with 85f0b311f983254a74b8d532abc8ac525df1e9df (set it as BRANCH here: https://jenkins.osmocom.org/jenkins/job/ttcn3-hnbgw-test/build). Then it used that commit, and when building again with the default of "*/master", it picks this proper commit now instead of the previous one. (I also looked if "*/master" could match another branch, but we don't have another in there that ends in master.)
Sounds like it will now be stuck on current master?
Updated by neels over 1 year ago
- Status changed from In Progress to Feedback
- Assignee changed from neels to osmith
Updated by osmith over 1 year ago
- Status changed from Feedback to Resolved
- % Done changed from 30 to 100
neels wrote in #note-2:
The build failure happens because msgb_sctp_msg_flags() is newly added to libosmo-netif.
Probably need to wait until the next nightly build happened for libosmo-netif
okay, then it should resolve itself by tomorrow.
neels wrote in #note-3:
- jenkin's git cache got confused when building with branch master again and kept checking out the previous commit 395cdbb41
Wiping the workspace didn't fix it. I also ssh'd into the node and verified that it really deletes the entire workspaceCould there be various workspaces on jenkins build slaves that still have a stuck git state?
I had checked a few other ttcn3-* jobs and none of them had this problem.
Sounds like it will now be stuck on current master?
A patch was merged to docker-playground. I just ran it again with the default of "*/master" as branch and it did select the proper new commit.
https://jenkins.osmocom.org/jenkins/job/ttcn3-hnbgw-test/230/
Marking this as resolved, let's maybe reopen it in case it still fails with the next libosmo-netif build.
Updated by neels over 1 year ago
On Tue, Sep 20, 2022 at 01:20:03PM +0000, osmith wrote:
Could there be various workspaces on jenkins build slaves that still have a stuck git state?
I had checked a few other ttcn3-* jobs and none of them had this problem.
My idea was more that the ttcn3-hnbgw-test job may be run on several distinct
build slaves, each having their own workspace copy.
Sounds like it will now be stuck on current master?
A patch was merged to docker-playground. I just ran it again with the default of "*/master" as branch and it did select the proper new commit.
ok, excellent.
I just triggered another build, and it builds as expected now.
Thanks!
~N