CESNET
FRRouting + libyang build
It can build using a set of well known verions of libyang, for some well known tags.
The purpose is to ensure that libyang and FRRouting keeps working together smoothly.
Currently, it is just about a compilation and link test.
In order to work with pre-set tags/versions, the fork should include the git tags. If they are missing, you can catch up those tags using: $ git remote -v origin [email protected]:vjardin/libyang.git (fetch) origin [email protected]:vjardin/libyang.git (push) upstream [email protected]:CESNET/libyang.git (fetch) upstream [email protected]:CESNET/libyang.git (push) $ git fetch --tags upstream $ git tag -l $ git push --tags origin
Run it once a day.
I am sorry but I still do not understand the purpose of testing a specific libyang version against any FRR version. The specific version code will never change so if it works once, it will always work. If FRR backports some fixes to older versions or they simply change for any reason, FRR should have an action that will check the compatibility with older libyang versions. Because even if this action fails at some point in the future, what can we do about it? It would be only because FRR changed.
Right, sorry, I forgot to drop "master" in order to have only "well known versions". This array for libyang and FRR can evolve over the time.
Actually, I was referring to libyang v2.1.128 as the specific version, which will never change. The only reason why you would want to keep testing, for example, FRR 8.5.4 with libyang 2.1.128 is if either of them will change in the future. Like I said, that is impossible for libyang but if that happens for FRR, it is FRR that needs to check its compatibility with the specific libyang version so I see no reason why it should run in libyang CI, FRR CI is the better place for it.
So, I am not sure why we have trouble understanding each other but I do not think this PR should be merged.
note: fixup FRRouting/libyang3 compilation: https://github.com/FRRouting/frr/pull/15608
@michalvasko : I'd be interested to get your review on this FRR patch about supporting the migration from libyang2 to libyang3. big THANKS.
I have taken a look and it seems fine, not that many changes. But I see that the biggest changes have not affected you and the ones I thought would not, did, too bad.
I have taken a look and it seems fine, not that many changes. But I see that the biggest changes have not affected you and the ones I thought would not, did, too bad.
Any chance you adjust libyang3 before it'll be released in order to optimise it ?
I have added some simple macros for better backwards compatibility.
thanks @michalvasko : it is being used by the latest updates from https://github.com/FRRouting/frr/pull/15608 ; your comments on this pull request 15608 would be welcomed @michalvasko please ?
cc: @idryzhov
My feedback is the same as it was before, I am still confused by testing specific libyang versions against specific frr versions, seems like a wasted CI time. The only thing that makes sense is testing libyang devel against whatever frr versions you want to support (and should be in libyang CI) and, in case frr has a similar development branch that is updated often with latest changes, test that branch against whatever libyang versions you want to be compatible with (and should be in frr CI).