-
Notifications
You must be signed in to change notification settings - Fork 3.3k
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
[TS] Add Build TS to CI jobs #6524
Conversation
LGTM other than the error, thanks for adding this! |
This now also includes a general clean up and removal of duplicate TS code gen artifacts. We have duplicate files here: https://github.com/google/flatbuffers/tree/master/tests/my-game I've opted to make sure all code gen ends up in the ts folder, because we have root level files that would end up in the tests folder which is already containing too many files and is not strictly generated content. I believe this could potentially be merged even if it fails on the new build TS step because it is just a silent failure on master right now. ping @krojew what is your review and opinion on this? |
../flatc --ts --gen-name-strings --gen-mutable --gen-object-api -o ts -I include_test monster_test.fbs | ||
../flatc --gen-object-api -b -I include_test monster_test.fbs unicode_test.json | ||
../flatc --ts --gen-name-strings --gen-object-api -o ts union_vector/union_vector.fbs | ||
if [ -x ../flatc ]; then |
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 think running tests with missing flatc makes much sense - it should rather fail immediately.
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.
The rationale is that we have the artifacts checked in so it's not really a requirement to run the tests, but it's practical when doing local development.
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.
When doing local dev, I don't really see a situation in which someone doesn't build flatc, but wants to run tests. What would be the purpose, since flatc is the thing being worked on?
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.
The argument for not requiring flatc is for the automated CI test run.
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.
Theoretically it can also be useful to be able to do development on https://github.com/google/flatbuffers/tree/master/ts without having to build and regenerate the code gen, but that's probably not important.
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.
We cannot treat those steps as independent - tests have to depend on building, otherwise they might be run before the building process. After all, we're testing the effects of the new build, not a collection of test files from an arbitrary point in time. If the build fails, we cannot test it => invariant is broken.
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.
But that means you consider the whole CI (at GitHub actions) setup wrong and I must disagree. CI passes only if all steps pass so naturally if we cannot build flatc the CI will not pass as a whole. And we do have a step that compiles flatc and explicitly verifies that the resulting code gen is exactly the same as is commited. If we did not commit code gen we would definitely have to do something else, but we commit the code gen for several good reasons.
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.
Notice that we also have a dependency between tests and build, although an implicit one - tests assume some step verifies committed test data comes from the current build. Explicitly stated or not, this is a kind of dependency. If the build output verification step disappears or silently stops working, tests will give wrong result, because their assumption (=dependency) gets broken. They will simply happily test old data.
Don't get me wrong - I'm not blocking merging this PR, but I think we have a problem with our CI configuration if we not only allow implicit dependency on build verification, but we also explicitly allow build to not exist.
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.
Ok I see your point about that the implicit dependency can be seen as too weak or unreliable, though I'm not sure I see it as a big issue.
Anyway I suggest merging this as it is better than nothing and cleans up the duplicate and confusing artifacts we have now.
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 am fine either way, but if it needs a tie breaker, I would agree that I prefer whatever setup fails harder/earlier whenever some part is missing, which would suggest @krojew's approach. But again it seems to be a minor difference in this case.
Appveyor fails with:
which appears to be in |
Unless I'm blind the generate_code.bat is tripping up because the windows version of flatc has some requirement on the input parameters that I fail to understand. :( |
The problem is now that the generated code is not the same as that generated by the CI: |
For whatever reason I didn't notice earlier that other languages also outputs code gen straight into tests folder, so I've gone back to that. It also exposed issue #6536. |
But still seems flatc.exe isn't happy complaining with "..\Debug\flatc.exe: error: invalid option location: -I". |
Finally found the problem, I had forgot to fix env var substition to be in the correct format for bat. This finally now looks be be passing. I've commited the transpiled js files too for not much other reason than that's it's messy to gitignore them and I suppose it doesn't hurt to be able to see the end resulting js in commit diffs. Note that I've excluded namespace_test from transpilation at https://github.com/bjornharrtell/flatbuffers/blob/ts-build/tests/tsconfig.json#L17 until #6536 can be resolved. |
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.
whole bunch of files directly in tests
, I think we want to avoid that
tests/book-reader.js
Outdated
@@ -0,0 +1,44 @@ | |||
// automatically generated by the FlatBuffers compiler, do not modify |
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 think these files should be directly in tests
, they aren't for any other languages.
Other languages only output to |
Ok @aardappel I think I could rework to a subfolder.. but even if as you say ts produce more files it's still a mess as is with other langs and I would say that a dedicated code gen folder for all langs would make sense. |
we could move more files of other langs to a subfolder as well, but no need to do that here. |
@aardappel but so can this be merged as is or? |
@bjornharrtell no, I don't think that would be a good idea.. this PR dumps a ton of files in |
@aardappel ok try to rework it. |
@aardappel done and hopefully acceptable now. |
Ping @aardappel |
Revisited and resolved your observations @aardappel, but now I also realize that the output is not different from other languages and there is no reason that it should have a dedicated ts folder. I will rework that now. |
@aardappel this is now again ready. Generated js files are intentionally added with the rationale that upgrades to fx. typescript compiler could affect the output and we want to see the diff changes from such events. |
All looks to be in the right spot! Thanks for hanging in there :) |
Attempt to resolve #6526