-
Notifications
You must be signed in to change notification settings - Fork 26
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Gitbase multi version testing #363
Gitbase multi version testing #363
Conversation
c8f4510
to
62bf6c6
Compare
I was thinking about a couple of things. Given that it is possible to test two given version of engine for retro-compatibility, and that this makes sense only for this kind of tests, maybe we could add another build flag such as
and
WDYT? |
BTW by running this:
I was able to detect the backward incompatibility. 🎉
and this:
succeeded. |
@smacker I didn't add the |
mhmmm for some reason it didn't execute the integration tests on travs... I'll investigate. |
I would better add it to make sure that the index is actually used by gitbase. Otherwise, they may show index in "SHOW INDEXES" but because it's outdated/calculated for a different directory they skip it when executing the query. But it's not like VERY important. |
4e45352
to
d88ff86
Compare
I have a similar comment to @smacker. I didn't test the current approach extensively, but my first impression is that it limits the usefulness of the integration tests in the local dev machine.
Did you check if we can use https://github.com/src-d/regression-core to download or build the binaries? |
true, this could be fixed easily I think.
true, I think that this could be solved by stashing/unstashing. But both things are actually not needed if we decide to test released versions only (which makes a lot of sense actually).
I forgot about it 😕. I'm gonna take a look into it 👍. |
This is currently on hold for this. |
if we go with src-d/regression-core approach it will make sense to follow the same workflow as other regression tests (a separate binary that runs on jenkins). Another thing if we embed struct correctly PR won't be that big & the code will be very localized without affecting anything else. So I don't think there should be a rush with merging. |
👍
Yup, I was thinking the same, we should discuss whether it makes more sense to do as you said. |
d88ff86
to
779a53f
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
some questions.
also after the long discussion, and the rebase push force I'm not sure about the state of this PR; if it already addressed al suggestions (on which I agree), or if there are still missing things.
Yup sorry for the force push, but there were so many changes that it would make the following rebase much more difficult. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
setupWd
is a dirty hack but I think it's okay to keep it for now
Yeah, I know 😞. I've realized later that |
What is the status of this PR? |
Yup, I was able to run it locally by patching it. |
pinged guys in #dev-retrieval. |
2cf3c4d
to
91f80a0
Compare
Maybe you would like to take another look. |
func (s *GitbaseBackCompTestSuite) setupWd() { | ||
s.T().Helper() | ||
|
||
_, filename, _, _ := runtime.Caller(0) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why do we need runtime.Caller(0)
here? Isn't it equal to os.Getwd
? If not could you please add a comment. It's not obvious at all.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
you're right, it took a couple of seconds even for me to remember the reason...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
addressed here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I still don't get it. We run both integration®ression tests using go test
So why do you need runtime.Caller
?
It still looks like:
_, filename, _, _ := runtime.Caller(0)
path.Dir(filename)
returns the same results as os.Getwd
And this new comment should belong to setupWd
function, not runtime.Caller
.
Or am I getting everything wrong?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
returns the same results as
os.Getwd
It's not path.Dir(filename)
actually, but path.Join(path.Dir(filename), "..")
.
So why do you need
runtime.Caller
?
Given that regression-core
needs the test to be run with the working directory set to the root of the project, I'm exploiting the path of the current file as a reference to build the path of the root of the project. So I'm using runtime.Caller
to get the path of gitbase_back_comp_test.go
.
And this new comment should belong to
setupWd
function, notruntime.Caller
.
Yup, it actually belongs to the whole function, gonna move it 👍.
} | ||
|
||
func AreSQLOutputEqual(s1 string, s2 string) error { | ||
return ParseSQLOutput(s1).RequireEqual(ParseSQLOutput(s2)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why do you need to parse results? Is there any problem with simple comparing strings?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
AFAIR it was for the rows ordering, but now I guess that we may force the query to include an ORDER BY
clause. But I don't know whether in the future we would need to test queries strictly without ORDER BY
clauses.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't mind to merge it as is. It just seems like an extra code that we can avoid so I mentioned it.
//cc @carlosms
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🤔 it's a shame to ask you to remove code that is already in place, but it's true that right now it's a bit convoluted.
If the only thing thing that prevents us from comparing the strings directly is the ORDER BY
, I think it's worth it to remove this extra code, to keep the code cleaner and easier to follow.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh no! I remember now! But I don't know whether we want to still keep it...
There's (was) another reason. When I developed this at some point it was in-between the replacement of the SQL cli, so there was a version using our custom sql cli and another using mysql cli.
In one case the headers were all capitalized and in the other not, and also if the header is composed by multiple words the separator in one case is the space and in the other was a dash. Moreover, in our sql cli the newline was \n
while on mysql is \r\n
, but this latter thing is a minimal problem as we can simply replace all the newlines of the buffer.
So if we still want to test versions previous to the sql cli replacement this is needed, but I don't know whether it does make sense to test such older versions.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I we were writing it now I would say we could ignore previous versions. Since it's already done maybe we can keep it, but let's add a comment explaining why this is done. Then later we can remove it if we don't use this to test older versions at all.
60aaedc
to
20e4f5a
Compare
Signed-off-by: Lou Marvin Caraig <loumarvincaraig@gmail.com>
Signed-off-by: Lou Marvin Caraig <loumarvincaraig@gmail.com>
Signed-off-by: Lou Marvin Caraig <loumarvincaraig@gmail.com>
20e4f5a
to
cca2deb
Compare
Signed-off-by: Lou Marvin Caraig <loumarvincaraig@gmail.com>
Signed-off-by: Lou Marvin Caraig <loumarvincaraig@gmail.com>
Signed-off-by: Lou Marvin Caraig <loumarvincaraig@gmail.com>
Signed-off-by: Lou Marvin Caraig <loumarvincaraig@gmail.com>
Signed-off-by: Lou Marvin Caraig <loumarvincaraig@gmail.com>
Signed-off-by: Lou Marvin Caraig <loumarvincaraig@gmail.com>
Signed-off-by: Lou Marvin Caraig <loumarvincaraig@gmail.com>
cca2deb
to
75779c2
Compare
Rebased, squashed and fixed conflicts. |
Are we ready to merge this then? |
Let's add this https://github.com/src-d/engine/pull/363#discussion_r272678247 as a comment in the code so it doesn't get lost |
Signed-off-by: Lou Marvin Caraig <loumarvincaraig@gmail.com>
Closes #336.
This PR adds integration testing that tests the compatibility of gitbase across different version of engine:
Two versions are considered that are named
PREV
andNEXT
. By defaultPREV
is the latest non rc version andNEXT
isHEAD
. For testing it is also possible to pass this as env vars in order to test two arbitrary version of engine: