Summary:
Pull Request resolved: https://github.com/facebook/yoga/pull/1781
This new image removed preinstalled libc++, and the ability to install old version of Clang Format we were installing.
This manually installs libc++ when setting up Clang jobs, and fully removes the clang-format validation job, since it wasn't correctly running before, and it's probably more a pain to ask people to run this than to just run Arcanist when importing a change.
Changelog: [Internal]
Reviewed By: joevilches
Differential Revision: D68455129
fbshipit-source-id: b5767be832b2b5d46db7e60e18b66823819ba15a
Summary: You need to provide the benchmark binary with a path to the captures. This is annoying and there is not a great way to do this in c++ that is cross-plat. So I just made this bash script to ease it. It can do buck and cmake.
Reviewed By: NickGerleman
Differential Revision: D53632438
fbshipit-source-id: 98b0ad52f91f2581e09f787da24f2ec2fff58bf4
Summary:
Pull Request resolved: https://github.com/facebook/yoga/pull/1566
In the previous diffs we serialized the in-memory representation of a node into json. This diff exposes a `generateBenchmark` method that reads from that json executes the proper public Yoga API functions to recreate the same tree. It then calls calculate layout so that we can time that in the next diff.
This diff is really only focusing on the core aspects of a yoga tree like style, children, and calculating layout; there are still more things to add coming up:
* Support for configs, experiments, and errata
* Support for measure functions
* Support for general node state that is not style (like always forming a containing block)
* Actually running all of these benchmarks together
* Tests
Reviewed By: NickGerleman
Differential Revision: D52987588
fbshipit-source-id: 7f7c9ca9956f693be62bc5e3cebdf1aed6f58aec
Summary:
> This PR is based on the proposal in https://github.com/facebook/yoga/issues/1538 inlined below, to integrate yoga with `oss-fuzz`
Hey yoga team,
I've recently become interested in yoga. I'd like to suggest and champion an effort to set up some basic fuzz-testing and combine it with google/oss-fuzz for continuous fuzzing. I'm fully aware that you are very busy people and I don't want to overload your review/maintenance capacity. Is this a bad time to discuss potential security/reliability improvements?
If you're not familiar with fuzzing or oss-fuzz I've included a few brief notes below.
#### **Benefits of Fuzz-Testing**
- **Dynamic Code Testing**: Fuzz-testing challenges systems with unexpected data, aiming to identify vulnerabilities or bugs. It’s akin to an exhaustive stress-test for the code.
- **Detecting Hidden Vulnerabilities**: It can uncover potential weaknesses that may not be evident in routine tests.
- **Continuous and Automated Testing**: With tools like Google’s OSS-Fuzz, fuzz-testing can be automated, running continuously on distributed systems, ensuring daily resilience checks.
#### **Google/oss-fuzz for Continuous Fuzzing**
- **Automated Fuzzing**: OSS-Fuzz undertakes comprehensive fuzz-testing daily on a distributed cluster.
- **Detailed Reporting**: OSS-Fuzz offers exhaustive reports in case of detected anomalies, enabling effective action.
I’d be more than happy to lead the effort in integrating fuzz testing with the yoga and assist in any way required.
#### Prior integrations
There have been a number of previous integrations completed with facebook repositories and google/oss-fuzz including;
- facebook/time
- facebook/zstd
- facebookexperimental/starlark-rust (this was me)
- facebook/proxygen
- facebook/hermes
- facebook/rocksdb
As a proof of concept I created a couple of super simple fuzz harnesses in https://github.com/facebook/yoga/issues/1537.
NOTE: Adding fuzz-testing and integrating with google/oss-fuzz was previously suggested here https://github.com/facebook/yoga/pull/1055 and was rejected. I think I've addressed the concerns raised in the first PR. While the original PR contained what was probably a higher performance fuzzer, the new fuzzer should be easier to integrate and doesn't introduce multiple sources of truth.
Pull Request resolved: https://github.com/facebook/yoga/pull/1537
Reviewed By: yungsters
Differential Revision: D52800366
Pulled By: NickGerleman
fbshipit-source-id: 4957282456f3263e600d13ae6f3e983681bebda6
Summary:
Pull Request resolved: https://github.com/facebook/yoga/pull/1467
1. Avoid reusing workflow names between validation and publish jobs, since they show up with the same UI when wanting to adhoc trigger a publish.
2. Merge SwiftPM checks into Validate Apple job
3. Merge remnants of website-next workflow into website workflow (and remove a redundant explicit build step already removed in one workflow)
4. Run more validation on push to release branch
5. Do not run website validation off of main, since it is only ever deployed from main branch
Reviewed By: cipolleschi
Differential Revision: D51236885
fbshipit-source-id: dd8165aa9871f173d8914f345569c6cde1edda72
Summary:
Pull Request resolved: https://github.com/facebook/yoga/pull/1334
Last change made me discover CMake on Ubuntu defaults to GCC. This change makes it so that we explicitly configure whether to use Clang/LLVM or GCC when building on machines with the `ubuntu-latest` image.
Reviewed By: christophpurrer
Differential Revision: D47462132
fbshipit-source-id: e81fb6d4b1740ab2913d39b6e90c52d674e5a4f2
Summary:
GitHub actions supports terminal colors, but most programs won't output color to a non-interactive terminal. We can control this via env variable, so that GTest output in GitHub actions is colorized.
Before:
{F847577544}
After:
{F847577610}
Pull Request resolved: https://github.com/facebook/yoga/pull/1218
Reviewed By: christophpurrer
Differential Revision: D42537630
Pulled By: NickGerleman
fbshipit-source-id: 28b22c061200026bf167c1a31d6a58445ba70214
Summary:
Pull Request resolved: https://github.com/facebook/yoga/pull/1217
This updates the CMake build present for being able to share options, fixing up flags, etc. A GTest build is added as well, along with a script and VSCode debug target so that OSS contributors can very easily run and debug tests on any OS.
Note that this isn't completely done (need to revise Windows, Mac, documentation), but should be finished enough otherwise for review.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D42406686
fbshipit-source-id: 95e7ba5e4751c496a171785490e85cf0097fa839
Summary:
We run validation workflows on push, but we do this for every branch, so dependabot PRs run every validation twice. We only really want push validation for the main branch.
Pull Request resolved: https://github.com/facebook/yoga/pull/1182
Test Plan: PRs still run
Reviewed By: cortinico
Differential Revision: D41741459
Pulled By: NickGerleman
fbshipit-source-id: 51abe2cc0c8c5b9c3fc8c8a20a585c9d5e868a5e
Summary:
This change starts adding more coverage to GitHub Actions. Existing workflows are split up to be per-platform, and stale scripts, etc are removed.
We are currently limited a bit by issues with the build itself, but this still adds a good bit of coverage that readily works, and adds places to inject more.
Another option would have been to move these to CircleCI where we have more credits, or used docker images instead of manual setup steps. etc, The Yoga build and number of changes is very light though, so we don't really need the complexity yet.
Some TODOs:
1. Fix the Apple Builds (pod lint and pod install return errors seen by the community)
2. Add working Android UTs
3. Add C++ UTs
4. Add Apple Publish
5. Add version stamping
Changelog:
[Internal][Added] - Start Adding Yoga GitHub Actions
Pull Request resolved: https://github.com/facebook/yoga/pull/1165
Reviewed By: cortinico
Differential Revision: D40386426
Pulled By: NickGerleman
fbshipit-source-id: c540dd25bfec6ac8c05e461c1236ef7fe6cb8598
