Skip to content
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

Merged
merged 29 commits into from
Apr 12, 2021
Merged

[TS] Add Build TS to CI jobs #6524

merged 29 commits into from
Apr 12, 2021

Conversation

bjornharrtell
Copy link
Collaborator

@bjornharrtell bjornharrtell commented Mar 20, 2021

Attempt to resolve #6526

@github-actions github-actions bot added the CI Continuous Integration label Mar 20, 2021
@bjornharrtell bjornharrtell changed the title Add Build TS to CI jobs [TS] Add Build TS to CI jobs Mar 21, 2021
@aardappel
Copy link
Collaborator

LGTM other than the error, thanks for adding this!

@bjornharrtell
Copy link
Collaborator Author

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
https://github.com/google/flatbuffers/tree/master/tests/ts/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
Copy link
Contributor

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.

Copy link
Collaborator Author

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.

Copy link
Contributor

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?

Copy link
Collaborator Author

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.

Copy link
Collaborator Author

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.

Copy link
Contributor

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.

Copy link
Collaborator Author

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.

Copy link
Contributor

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.

Copy link
Collaborator Author

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.

Copy link
Collaborator

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.

@aardappel
Copy link
Collaborator

Appveyor fails with:

..\Debug\flatc.exe: error: unknown commandline argument: -ts

which appears to be in generate_code.bat

@bjornharrtell
Copy link
Collaborator Author

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. :(

@aardappel
Copy link
Collaborator

The problem is now that the generated code is not the same as that generated by the CI:
https://ci.appveyor.com/project/aardappel/flatbuffers/builds/38406295/job/xsj2ogfk7xc0cj74

@github-actions github-actions bot added the c++ label Mar 26, 2021
@bjornharrtell
Copy link
Collaborator Author

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.

@bjornharrtell
Copy link
Collaborator Author

But still seems flatc.exe isn't happy complaining with "..\Debug\flatc.exe: error: invalid option location: -I".

@bjornharrtell
Copy link
Collaborator Author

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.

Copy link
Collaborator

@aardappel aardappel left a 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

@@ -0,0 +1,44 @@
// automatically generated by the FlatBuffers compiler, do not modify
Copy link
Collaborator

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.

@aardappel
Copy link
Collaborator

Other languages only output to tests if the entirety of the schema compiles to a single file, not for the "one file per type" style that TS uses.

@bjornharrtell
Copy link
Collaborator Author

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.

@aardappel
Copy link
Collaborator

we could move more files of other langs to a subfolder as well, but no need to do that here.

@bjornharrtell
Copy link
Collaborator Author

@aardappel but so can this be merged as is or?

@aardappel
Copy link
Collaborator

@bjornharrtell no, I don't think that would be a good idea.. this PR dumps a ton of files in tests which is to be avoided. Like I said, the languages that have files directly in tests like C++ do so because they produce just a single file per schema, which is much less of a problem than the many files TS generates. All other languages have their files under MyGame.

@bjornharrtell
Copy link
Collaborator Author

@aardappel ok try to rework it.

@bjornharrtell
Copy link
Collaborator Author

@aardappel done and hopefully acceptable now.

@bjornharrtell
Copy link
Collaborator Author

Ping @aardappel

tests/ts/rapunzel.ts Outdated Show resolved Hide resolved
tests/ts/optional_scalars/scalar-stuff.ts Outdated Show resolved Hide resolved
@bjornharrtell
Copy link
Collaborator Author

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.

@bjornharrtell
Copy link
Collaborator Author

@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.

@aardappel
Copy link
Collaborator

All looks to be in the right spot! Thanks for hanging in there :)

@aardappel aardappel merged commit 408e4db into google:master Apr 12, 2021
@bjornharrtell bjornharrtell deleted the ts-build branch April 12, 2021 20:12
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[TS] Test are not run by CI
3 participants