- 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
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
vovasty
Huy Nguyen
Jakub Kašpar