-
Notifications
You must be signed in to change notification settings - Fork 598
Conversation
I decided to remove the Travis CI special settings because some of them were outdated settings which were needed to use a modern C++ compiler. We are now on a more modern version of Ubuntu, so it's not needed anymore. Also With the other One of the benefits I see is that the build completed in 1 hr 45 min. This is down from the nearly 3 hour long builds. I'm not sure what the difference was. One theory is maybe it was due to us re-running the style check on each stage of the process (build, non-flaky unit test, flaky unit test). Another theory is that by limiting the memory used and also the jobs to 25, maybe that slowed things down. But I'm taking this opportunity to test TravisCI and it seems like it's working. |
Yes, this is awesome! 🥳
We should document this in the build script as well as the online documentation? @joshfischer1108 has this alleviated your build issues on Apple Silicone? |
Updated the Compiling overview, compiling linux and compiling MacOS pages in the docs. Also found some other issues with old version of Bazel being referenced (0.26). I updated our docs to use Bazelisk, which automatically manages the verzion of Bazel. This will save us from having to update the docs each time we bump the version. This was especially annoying each time because of the old versioned docs in the repo that should not be updated. |
Some other Here is an example linked off of the Bazel issue in which they document the fact that JDK 11 resolved many Docker related issues. bazelbuild/bazel#6592 |
I also removed mention of |
I was just looking through the build logs and I am not sure if I am interpreting what I am seeing correctly but the only set of tests that seem to be running are the integration tests. #10424 passed===========================================================
heron build 0:59:59
heron test non-flaky 0:04:48
heron test flaky 0:01:18
heron build tarpkgs 0:01:10
heron build binpkgs 0:00:37
heron build docker images 0:01:12
===> Finished scripts/travis/build.sh at 2022-02-27 22:33:10 (1:09:06)
===> Starting scripts/travis/test.sh at 2022-02-27 22:33:14
===> Starting heron build integration_test at 2022-02-27 22:33:14
bazel build integration_test/src/... > heron_build_integration_test.txt
64 seconds 30 log lines
`bazel build integration_test/src/...` finished with errcode: 0
===> Finished heron build integration_test at 2022-02-27 22:34:18 (0:01:04)
===> Starting heron install at 2022-02-27 22:34:18
bazel run -- scripts/packages:heron-install.sh --user > heron_install.txt
18 seconds 34 log lines
`bazel run -- scripts/packages:heron-install.sh --user` finished with errcode: 0
===> Finished heron install at 2022-02-27 22:34:37 (0:00:19)
===> Starting heron tests install at 2022-02-27 22:34:37
bazel run -- scripts/packages:heron-tests-install.sh --user > heron_tests_install.txt
6 seconds 34 log lines
`bazel run -- scripts/packages:heron-tests-install.sh --user` finished with errcode: 0
===> Finished heron tests install at 2022-02-27 22:34:43 (0:00:06)
===> Starting heron integration_test local at 2022-02-27 22:34:43 ===> Finished heron integration_topology_test java at 2022-02-27 23:12:55 (0:04:36)
===> Task duration summary for scripts/travis/test.sh
===========================================================
heron build integration_test 0:01:04
heron install 0:00:19
heron tests install 0:00:06
heron integration_test local 0:05:55
heron integration_test http-server initialization 0:00:00
heron integration_test scala 0:02:45
heron integration_test java 0:18:30
heron integration_test python 0:06:25
heron integration_topology_test java 0:04:36
===> Finished scripts/travis/test.sh at 2022-02-27 23:12:55 (0:39:41)
===> Task duration summary for scripts/travis/ci.sh
===========================================================
scripts/travis/build.sh 1:09:06
scripts/travis/test.sh 0:39:41 Are the "regular"/non-integration battery of tests still run? I may have missed the output in the logs. I remember |
Interesting. I see them mentioned, but it's hard to tell with the way to log output is hidden away. I'll do some local testing. |
I think everything is okay with the tests. I did not see anything in the diff which would turn it off and this PR run log has the same sort of output without |
46b07c7
to
2868547
Compare
They were outdatted and commented out anyway.
2868547
to
ea0f744
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Lots of really important changes in this PR.
Great work on this PR, there are some really important changes. I know some of these changes are cascading and build on/require each other but it would be better to introduce them as multiple small PRs. This way if there is an issue with some of the changes, we can revert the culprits without losing all changes. I would get @nwangtw to once over and approve the changes before merging. It looks good to me. I have a few comments/questions - none of which would hold anything up on my end. It would be nice if @joshfischer1108, or someone else with an Apple Silicone machine, could let us know if they are encountering any other build issues. |
|
Just tested on the ubuntu22.04, and found that, |
…nyone trying to build Ubuntu 22.04 image
@windhamwong I added a comment above the |
|
|
+1 Hmm I don't have a Reviewer, so I don't have an Approved button. |
We need to get you added to the Apache Foundation Github Org as a contributor. Have you done the necessary steps to get this enabled after you were given committer access to the repo? |
I will attempt to build this weekend. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have no issue with the PR
I can build on ubuntu20.04 andubuntu22.04
Yes, I Want |
Thank you, it would be great to know if all is well on Apple Silicone. Choi Se confirmed everything is building on Apple x86_64.
Let us get this set up so he can merge PRs. |
Add back missing Dockerfile for Ubuntu22.04
I think this is now ready to merge. For the Apple M1 support. I think this currently won't yet support it. But primarily because we need to add some missing ARM dependencies. For example the |
Completely agree and Apple Silicon support should not block this. It has a lot of very broad and required changes. |
Resolved a silly merge conflict in the |
Some build script cleanup leveraging the Bazel platforms feature.
https://github.com/aosp-riscv/platform-build-bazel
Context below:
While working through a bug we ran into with MacOS failing to compile, I got a better understanding of some of the Bazel settings. In another thread with Josh, who is compiling on the Apple M1 for the first time, he ran into issues with Linux vs OSX.
It dawned on me that we were explicitly setting the config to modify a number of settings. Some of them include the following items:
In a recent PR, I collapsed all of the Linux flavors to a standard
--config=linux
. This was born out of my frustration with the build scripts not jiving with Bazel standards. But it was not actually solving the problem. I'm hoping that this PR will help resolve some of the issues.Changes:
--config
. Bazel will detect the OS automatically.fastbuild
, but you can add-c opt
to build optimized build.a. You can even build both side by side with Bazel making a folder like darwin-fastbuild and darwin-opt3. If you want to run stylecheck, you can add
--config=stylecheck
tools/platform/BUILD
tools/platform/BUILD
6. Scripts outside of Bazel were updated to remove--config
.-c opt
or--config=stylecheck
when needed.