* Fix: Transfer leadingScreensForBatching from pending state on node load
and add tests
* Address PR comments
* try to fix build
* Adding whitespace to see if builds run
* Revert prev commit to check if builds are working
---------
Co-authored-by: Gianmarco <gfolchi@pinterest.com>
* Add default image provider
## Summary
Right now image nodes hardcode logic to use either PINRemoteImage or the basic image downloader. Additionally, Texture is missing annotations for nullability and sendable for several of the image blocks and types.
Introduce ASDefaultImageDownloader as a singleton. It takes blocks to return the default image downloader and image cache. Update both image nodes to use this. By default ASDefaultImageDownloader uses the same logic the image nodes used to, so change in behavior.
## Test plan
Run the Kittens example and verify it works.
* Appears we need Xcode 16.4
* And need at least 18.5
* Update to Xcode 15
## Summary
We want to make Texture build with recent tools like Xcode 15. Part of this is bumping the minimum supported OS to iOS 14.
I only removed the dead code (i.e. code gated on versions older than iOS 14). There are still some warnings about outdated APIs in use, but they are non-trivial changes to fix.
## Test plan
Run all the examples. Run all the unit tests and make them pass.
* Use Xcode 15.3 so we have 17.4 simulators
* Fixing an asset catalog compiler error when building against iPhone SE
* Fix a couple of file extensions for assets
A couple of PNGs were marked as JPGs
* Try to get CI to work
* update to xcode that exists
* Use a more recent sim; update podfiles not to use github as source
* fix clang 10 error about 10 being extern
* don’t override deprecated method
* Fix tests and snapshot tests
It looks like github updated so that `macos-latest` is now macos-11. It can't find Xcode_11_5. Let's try to set the runs-on version explicitly and see if some magic happens.
also allow warnings for podlint because that started failing too
- We recently let a couple of issues slip through code review becase we don't lint our podspec on pull requests since the task takes too long (about half an hour). To prevent this from happening again, this PR adds 2 new CI jobs that lint default and other subspecs on all PRs. By splitting into 2 tasks, the impact on total CI time should be mitigated somewhat. There is still a master-only task that lint all subspecs as the last line of defense in case the 2 new tasks miss any.
* Update ci.yml
Add name to the script run phase
* Revert back Dangerfile and remove danger JS, create separate workflow for push for tests and for PR for tests + danger, run ruby danger as part of the PR check
* remove PR ci
* Revert "remove PR ci"
This reverts commit 839ba3ae2a.
* cahnge token to default one
* PR feedback
* Rename danger.yml name
Turned out that @babel/plugin-transform-flow-strip-types is needed for TypeScript/Bale transpilation with we don't need because we use JS. So instead of installing the module, we can. just disable transpilation by DANGER_DISABLE_TRANSPILATION environment variable to true.
Test plan: Tested manually here: https://github.com/TextureGroup/Texture/commit/a4cfe347914c23aafe08603bf82372d4cb94136c/checks
In #1627 I introduced an approval step that is meant to block PRs from forked repos unless they're labeled as "CI approved" by a maintainer. Turned out it doesn't work. When a label is added, a pull_request event with "labeled" as its action is fired but GitHub CI didn't restart the workflow. My guess is it checked the PR's commit and branch and determined that nothing has changed. Here is what the doc says: "A workflow runs on a specific version of code in your repository, determined by the commit SHA and Git ref" (https://help.github.com/en/articles/events-that-trigger-workflows#webhook-events).
This diff removes the label check so all PRs are automatically built. Here are the current usage limits in case we run into them: https://help.github.com/en/articles/workflow-syntax-for-github-actions#usage-limits
GitHub Actions now supports CI and it's free for open source projects!
Our current CI runs on a single machine and needs 1h 20m for each build. GitHub CI often finishes everything in less than 10m!
The setup is straight-forward. The only missing feature is the ability to exclude certain files so that if a commit only contains those files, the CI won't test it at all (see exclude-from-build.json). Given that GitHub CI is fast and is not a serial queue, I wouldn't mind testing such commit as well.
* Fix and optimize steps that build example projects
- examples-pt3 builds the same examples as examples-pt1 instead of building the remaining projects. So I fixed it.
- Add another mode (examples-pt4) to distribute the load with existing steps.
- Build extra examples (examples-extra-pt{1, 2, 3}) which weren't built before.
- Each examples-pt and examples-extra-pt builds 5 projects except examples-pt4 and examples-extra-pt3 which build 6.
* Use HTTPS URL for Weaver in Podfile of examples/ASDKgram
* Don't build extra examples for now
GianmarcoandGianmarco
Andy Finnell
ricky
Garrett Moon
Jon Parise
vovasty
Huy Nguyen
Jakub Kašpar
Garrett Moon
Hannah Troisi