First of all, thanks for your effort of improving Weex CI. I know debugging TravisCI is a painful experience and you have wrote over one hundred commits [1] to make TravisCI right.
If this is about dependencies in source code, you should definitely copy those code into weex_sdk and change the LICENSE file to make third-party IP clear. As this is about dependencies in CI environment, and the corresponding code will never be bundled into the release of weex_sdk, I think forking others' repo is acceptable. Even so, I don't think it's ok that you relies on a certain branch of the forking repo [2]. At least you should publish a release version for your forking repo and relies on that version in weex_sdk. Maybe mentors here could give some advice on this issue as it's not the same source code dependencies issue that I am familiar with. @Jan @Myrle @Willem [1] https://github.com/apache/incubator-weex/pull/2731 [2] https://github.com/apache/incubator-weex/blob/79494d2027760d9d6ba6d8ae807c6e155896df08/Gemfile#L11 Best Regards, YorkShen 申远 王仁敏 <[email protected]> 于2019年8月6日周二 下午3:04写道： > Recently I spent some time on Travis CI, the below is the progress： > > 1. Added Android Lint check and OCLint check in Travis CI. > > - > > [Android Lint] > > If the files in the android folder are modified, new-created, or deleted, > the AndroidLint check will be triggered. Once any rules of AndroidLint are > triggered, Travis CI will build failed and the result of AndroidLint will > be displayed at the PR. (We have solved all the problems reported by > AndroidLint) > > - > > [OCLint] > > If the C++ or Objective-C files are modified, new-created, or deleted, the > OCLint check will be triggered. OCLint is the same as Android Lint, Once > any rules of OCLint are triggered, Travis CI will build failed and the > result of OCLint will be displayed at the PR. (We are solving all the > problems reported by OCLint and will complete soon.) > > But there are too many rules of OCLint and many of them have a little > effect on our project. So we disable some of the rules, as the is shown. > > 2. Add Check of the iOS project. > > Only ios-sdk project build successful and all the test cases of the > ios-playground pass, the check will succeed. otherwise, The Travis CI will > build failed. > > 3. Add code-format validation check. > > use Clang-Format to validate the code format, as Clang-Format supports code > format of the llvm languages, such as c++, objective-c, java, etc. > > I found a danger plugin named danger-code_style_validation > <https://github.com/flix-tech/danger-code_style_validation> almost > satisfied our needs. it uses 'clang-format' to look for code style > violations in added lines on the current PR and offers inline patches. > > To meet our needs, I fork that repo and I did some change based on it : > > 1. > > change message level from error to warn(because I think the code format > is recommended and not necessary.) > 2. > > modify the message hint and make it more readable. > > In Travis CI, the Weex project will download this plugin through a GitHub > link and use it to validate code-format. here is the configuration > < > https://github.com/apache/incubator-weex/blob/79494d2027760d9d6ba6d8ae807c6e155896df08/Gemfile#L11 > > > . > > but I am not sure whether this behavior meets the requirements of AFS, If > not, what should I do? > > > Links: > > OCLint diable rule: > > https://github.com/apache/incubator-weex/blob/79494d2027760d9d6ba6d8ae807c6e155896df08/.travis.yml#L167 >
