Currently rlImport will only putput following message: :: rlImport: Found 'sblim/main' in /mnt/tests :: rlImport: Will try to import sblim/main from /mnt/tests/CoreOS/sblim/Library/main/lib.sh However, if library has changed recently, (which can be often in situations as debugging a new library), it's useful to be able to check in TESTOUT.log if test was really run with the newest version. This should be as simple as printing the version during the import.
I believe this bug should go for beakerlib, not workflow-tomorrow.
I like this. Personally, I use internal versioning in my libraries and I just echo out that version during sourcing. There is no agreed internal versioning of the libraries. There is also possibility to use rpm version containing the library which can be currently found in beaker logs. What kind of version do you mean? What if the library is installed other way than from rpm? May be we can establish some new recommendation to include variable like <PREFIX>_VERSION or so which could, in time, change to requirement.
(In reply to Dalibor Pospíšil from comment #2) > [...] > > What kind of version do you mean? What if the library is installed other way > than from rpm? Well if the code can't determine the version it's OK if it prints "unknown". ~ > May be we can establish some new recommendation to include variable like > <PREFIX>_VERSION or so which could, in time, change to requirement. Well there are multiple potential sources of task/library versioning data: * git * RPM * Makefile * lib.sh * in future, we could even have meta.yml (jjaburek's Test Metadata Project). I hear that Makefile is being obsoleted any time so it's out of the game. Git is usually not distributed to the testing machine so what's left is * RPM * lib.sh * maybe meta.yml Note that we already have a mandatory versioning in producing of *.rpm, so 1. try *.RPM version 2. just print "unknown" or something should work immediately. ~ Now the other question is: what can we do to support versioning *and* RPM-less distribution? Having two sources of such information is obviously dangerous so it's likely that other place (lib.sh/meta.yml) would become the next authoritative source. I suggest opening discussion on this topic on urt-list. However, once that is solved, the above code can be easily extended to: 1. try *.RPM version 2. try lib.sh/meta.yml 2. just print "unknown" or something provided that RPM versioning would reflect the new one (just as it works in distribution channels), which would need to anyway.
Created attachment 953026 [details] rlImport prints version of imported library Hello, I have created patch for this bug, check it and tell me what do you think about it. I've tested it with some basic tests and it seems to be working.
I forgot to mention, you have to use [-V/--version] parameter to print library version. It's because in case that user doesn't need to print out version of library and tests are faster without printing the version.
Created attachment 953950 [details] rlImport prints version of imported library I've created second patch for this bug, it extracts version from comment line "# library-version = number" in lib.sh . If the comment line is missing try to find rpm and it's version otherwise just print uknown. Also I've added to Beaker: Libraries Documentation section Versioning where is stated use of this.
Thank you for patches! Some notes: (In reply to Marek Marusic from comment #5) > I forgot to mention, you have to use [-V/--version] parameter to print > library version. It's because in case that user doesn't need to print out > version of library and tests are faster without printing the version. How much slower? I haven't looked much closely at your patch but if it takes "long" we might have bigger problem. Anyway, I guess that in typical case when you need to be sure about the version is when you are looking at logs *after* something has gone wrong. So I think it would be more useful to make the printing implicit. For this reason, I'd even go for it if there is as huge price as, say 1s per import. > If the comment line is missing try to find rpm and it's version otherwise just print uknown. To me it would make more sense to stop at RPM version if it's found (which is almost always). I'm afraid that reality, comment file version may (and will, in many cases) stay the same over few RPMs, therefore the information printed will become insufficient. In fact, I would even discourage from using the comment line version at all. Having the comment-line up to date is dependent on human factor and IMHO very cumbersome: in normal workflow, version is determined by `make tag`, which happens after you have edited all files. Therefore you'd have to pre-dict the version and edit the line before issuing that command. That said, I don't doubt that some people do keep their comment line version updated, for that reason it seems OK to have it as a "last resort", but even in that case it could be useful to mention that in the output (unless it's clear from the formatting).
(In reply to Alois Mahdal from comment #7) > Thank you for patches! > > Some notes: > > How much slower? I haven't looked much closely at your patch but if it > takes "long" we might have bigger problem. Current implementation does not need any -V option. > > > If the comment line is missing try to find rpm and it's version otherwise just print uknown. > > To me it would make more sense to stop at RPM version if it's found (which > is almost always). > > I'm afraid that reality, comment file version may (and will, in many cases) > stay the same over few RPMs, therefore the information printed will become > insufficient. > > In fact, I would even discourage from using the comment line version at all. > Having the comment-line up to date is dependent on human factor and IMHO > very cumbersome: in normal workflow, version is determined by `make tag`, > which happens after you have edited all files. Therefore you'd have to > pre-dict the version and edit the line before issuing that command. > > That said, I don't doubt that some people do keep their comment line version > updated, for that reason it seems OK to have it as a "last resort", but even > in that case it could be useful to mention that in the output (unless it's > clear from the formatting). This commented attribute should be just optional and it should not be in the template or at least not active (live using '##' ate the beginning of the line). I personally use internal versioning and increment it only if important changes occur, that is the rpm versioning is faster then mine. I do not increment version e.g. for doc change. I agree that once the internal version is present it can be broken at any time. The solution could be to print both versions but I do not want to flood the output.
(In reply to Dalibor Pospíšil from comment #8) > [...] > I agree that once the internal version is present it can be broken at any > time. The solution could be to print both versions but I do not want to > flood the output. I like the idea of printing both---IOW all version info available. In some cases the information can be crucial to quickly identify the cause so I would not call it flooding.
I wanted to avoid multiple versions to allow to work with them. I.e. to be able to compare the version in the test code and may be behave differently. But also I do not know if this would any useful.
(In reply to Dalibor Pospíšil from comment #10) > I wanted to avoid multiple versions to allow to work with them. I.e. to be > able to compare the version in the test code and may be behave differently. > But also I do not know if this would any useful. Many programs are able to access/print their own version number but that's just for informing *others*, e.g. so that they know if API is compatible. Yet I can't imagine any good reason to change "own" behavior based on own version number: Complete misunderstanding of whole purpose of versioning? Or a cry for help above a broken (desperately broken, above engimeer's deepest and darkest nigthmare) versioning? A joke? A philosophical experiment? Code opetry? Or a pure insanity? My point was to print the most precise version info available so that others (i.e. users--be it author or other engineers--reading output) can see. I liked printing both as simpler, less disrupting alternative than implementing logic "which version info to print".
fixed by https://git.fedorahosted.org/cgit/beakerlib.git/commit/?id=bd472e47a4e319bbfe58a39dd7c19610acfe8208