libyang checks: start with FRRouting #2203
Conversation
It can build for the current pull request of libyang, for some well known tags in order to have a reference too. 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 the 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
Even if a build fails, we'd like to continue on failures. But in case of a failure it needs to yell that it does not succeed. apply the mustache rule per: https://docs.github.com/en/actions/learn-github-actions/expressions#status-check-functions
.github/workflows/frr-checks.yml
Outdated
| compiler: [ gcc ] | ||
| frr-versions: [ master ] | ||
| libyang-versions: | ||
| - v2.1.128 |
There was a problem hiding this comment.
Why use a specific version? What sense does it make to use the same version every time? It will not use the latest changes that should be tested I assumed.
There was a problem hiding this comment.
It is to have a reference and to start this question to be transparent.
There are 2 sides:
- on FRR side, you are right, it should compile with many libyang versions ; I'll work on it.
- on libyang side, you are right, 1 libyang should compile with many FRR versions ; for the sake of this merge request, I am just using "master" of FRR.
I could drop v2.1.128 from the pull request checks, but I feel that it should run on a scheduled Action : what's about once a day for instance ?
There was a problem hiding this comment.
Once a day is fine but we have used triggers for now so it can also be on every push (to devel ideally because master is changed only on release).
There was a problem hiding this comment.
@michalvasko , see 8d644ca which shows how such matrix of cases could be managed from FRRouting side too.
There was a problem hiding this comment.
I am still not sure I understand. For libyang, I would think you always want to test the latest version with latest changes whether there were no incompatibilities introduced. As for FRR, I guess there could be several versions to check that none of the supported FRR versions were broken.
There was a problem hiding this comment.
@michalvasko > For libyang, I would think you always want to test the latest version with latest changes
@vjardin > yes, so I did update the pull request dropping the specific version of libyang for the time being. A full set of matrix run should be for a scheduled job.
@michalvasko > As for FRR, I guess there could be several versions to check
@vjardin > yes, so the array:
frr-versions:
- master
will be extended accordingly after this pull request.
There was a problem hiding this comment.
Okay, so please fix the initial current libyang - frr master build so that it finishes successfully.
There was a problem hiding this comment.
Hmmm 🤔 currently I cannot since the evolutions of libyang break the applications using it like FRR. So I'd suggest the following :
- step1: merge it asis so this pull request is focused on this template for such Action
- step2: fix current libyang - frr master to comply and be successful (as you suggest)
- step3: add scheduled build with tags / versions matrix for a broader nightly check
Is it ok for you ?
There was a problem hiding this comment.
Is it ok for you ?
Not really because I do not understand.
- Why merge an action that is going to fail? Why not wait until it actually succeeds?
- Yes, it is up to you to do this (after libyang is released) and then a successful action can be added.
- This is an option although I prefer actions triggered by some changes (push), similarly to our
devel-pushaction.
There was a problem hiding this comment.
OK, I get your point related to 1. and 2. I'll follow your suggestion "fix first", or least I'll explore it deeper.
Regarding 3. ; I'll submit a specific pull request that leverages "scheduled build" only using v2.1.x and then later, once issues will be fixed, it can be extended (which I do prefer like you) with an action on every push.
Let's have a symetric design for libyang and FRRouting.
Drop the explicit version v2.1.128 to avoid running it on every pull request/push. A scheduled run on specific tags will be provided by a later commit. Suggested-by: Michal Vasko <[email protected]>
|
I am closing this pull request and I'll (re)open a new one once issues will be fixed. |
|
Alright, up to you, I do not mind it being open until it can be merged. |
Hi,
the main purpose of this pull request is to be able to have a framework to test libyang (including the current pull requests, some tags for references) along with the libyang in order to easy the shared integration.
It starts with FRRouting, but it can be extended with other projects.
Currently, it is a test based on compile and link. Once it'll be merged, I can extend it for some few smoke tests from the projects that consume libyang so they can report a proper execution of their smoke tests.