Correct me if I am wrong. It looks like you are relying on third-party code only for code_format task in TravisCI. If this is the case, I suggest you remove code_format task in your PR first, as everything else looks good to me, I could just merge your PR at that time. Then we can still discuss how to solve the third party dependencies, as it’s a time consuming task according to my knowledge.
> 在 2019年8月6日，16:10，申远 <[email protected]> 写道： > > 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 > <https://github.com/apache/incubator-weex/pull/2731> > [2] > https://github.com/apache/incubator-weex/blob/79494d2027760d9d6ba6d8ae807c6e155896df08/Gemfile#L11 > > <https://github.com/apache/incubator-weex/blob/79494d2027760d9d6ba6d8ae807c6e155896df08/Gemfile#L11> > > Best Regards, > YorkShen > > 申远 > > > 王仁敏 <[email protected] <mailto:[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 > <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 > > <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 > > <https://github.com/apache/incubator-weex/blob/79494d2027760d9d6ba6d8ae807c6e155896df08/.travis.yml#L167>
