OK, in the end I went with simply `pinned`. When I was updating the commit, it
became apparent "mutable" just didn't fit well in the context, and also clashed
with the other meaning I'd mentioned...
--
Reply to this email directly or view it on GitHub:
@dmnks pushed 1 commit.
42b6792c91dd951e21ab37485955fa68195009cd Add support for "pinned" tests
--
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2803/files/2973e1957638cae6807783ee6f50e13b248164f9..42b6792c91dd951e21ab37485955fa68195009cd
You are receiving this because
Yup, annoyingly as well as amusingly long :smile: But as a rule of thumb,
naming make targets after the "artifacts" they produce rather than the "action"
they do is always better, at least IMO (of course we don't follow that
precisely but that's fine).
--
Reply to this email directly or view
Yeah, mutable and immutable are generic concepts and used in multiple places
already. So if you really want to pinpoint it, "update-mutable-tests" :smile:
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2803#issuecomment-1849773127
You
Oh! That's a pretty good idea! :smile:
... except that "mutable" is already used in the test context. But - that
doesn't matter much, I suppose. It's a lower-level detail that's relevant when
*writing* a test. Otherwise, "mutable" is indeed the best fit.
So, let's just go with that.
--
Leafing through the mental dictionary of handy words...
Mutable! It fits the bill pretty perfectly as these results are *expected to
change* at certain times, whereas all the other tests do not. So perhaps
"update-mutable"?
--
Reply to this email directly or view it on GitHub:
And perhaps, if we were to put all the test-related targets behind the "check-"
prefix, then "check-update"...
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2803#issuecomment-1849711377
You are receiving this because you are subscribed
... which makes me think about another target name: update-tests :smile:
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2803#issuecomment-1849710161
You are receiving this because you are subscribed to this thread.
Message ID:
The idea behind this kind of tests is basically this: We need to *track* the
expected output in the repository so that we ensure it's always the same when
running the given test, which is why don't just dynamically determine the
expected output at test-runtime. At the same time, we need this
"version-diff" indeed is perhaps closer to what it does, however it just
happens that these tests depend on the version. There might as well be other
tests (in the future) that depend on some other baked-in value.
"release-prep" is similarly too generic because this really is just about the
For other random ideas, perhaps something better would be in the direction of
what it actually does, eg "version-diff", or what it relates to: preparing for
release (release-prep) or such.
--
Reply to this email directly or view it on GitHub:
Pinned is not really descriptive but at least it wont be confused with
something else in the build system domain. But yup, perhaps we can come up with
something actually descriptive. Names are hard :laughing:
--
Reply to this email directly or view it on GitHub:
Yup, I knew the "static" name probably wasn't great because of what you said
but also because those tests aren't really "static" any more than the normal
tests, actually quite the opposite :smile:
For some reason, "pinned" doesn't sound very descriptive either, though. And
"check-pinned" even
Heh, I was so used to the old procedure that the idea of somehow improving it
never crossed my mind :sweat_smile:
"static" as a target name is problematic though, "static" in the build system
context usually means static linkage. Maybe "pinned", or as per the the README,
or "check-pinned" to
@dmnks pushed 1 commit.
2973e1957638cae6807783ee6f50e13b248164f9 Extract static tests for easier
release bumps
--
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2803/files/923482342cd0f159689d4076613cedb92503f0a7..2973e1957638cae6807783ee6f50e13b248164f9
You are
@dmnks pushed 1 commit.
923482342cd0f159689d4076613cedb92503f0a7 Extract static tests for easier
release bumps
--
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2803/files/2ac031db454b5a84a4d7d39e6bd5dfa1be8fde42..923482342cd0f159689d4076613cedb92503f0a7
You are
Whenever we bump the RPM version in cmake, certain tests also need updating,
e.g. those that compare package digests or RPM sonames as those are subject to
the version number.
Up until now, this had to be done manually by running the test-suite, looking
at the failed tests diffs and fixing up
17 matches
Mail list logo
