-
Notifications
You must be signed in to change notification settings - Fork 3.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Replace Travis with Github Actions for CI builds #6071
Conversation
fd52c15
to
93e5cc8
Compare
@@ -514,7 +514,7 @@ if(ENABLE_MASON) | |||
set(CMAKE_MODULE_LINKER_FLAGS "${CMAKE_MODULE_LINKER_FLAGS} ${LINKER_FLAGS}") | |||
|
|||
# current mason packages target -D_GLIBCXX_USE_CXX11_ABI=0 | |||
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -D_GLIBCXX_USE_CXX11_ABI=0") | |||
add_dependency_defines(-D_GLIBCXX_USE_CXX11_ABI=0) |
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.
On Travis Trusty builds, the compilers all had GLIBCXX_USE_CXX11_ABI=0
by default. This setting has been flipped in Bionic, so we need to explicitly pass this to pkg-config so that the example builds.
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 forgot why we had this in the first place. I think this was mason related given that is afaik the only place where we care about ABI of our binaries.
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.
Yep, the Mason Boosts are built against the old ABI .
@@ -244,14 +242,15 @@ bool RestrictionParser::ShouldIgnoreRestriction(const std::string &except_tag_st | |||
|
|||
// Be warned, this is quadratic work here, but we assume that | |||
// only a few exceptions are actually defined. | |||
std::vector<std::string> exceptions; | |||
boost::algorithm::split_regex(exceptions, except_tag_string, boost::regex("[;][ ]*")); | |||
const std::regex delimiter_re("[;][ ]*"); |
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.
Similar problem to the Travis Xenial upgrade attempt.
Boost.Regex and GCC5 appears to be buggy with respect to [abi:cxx11]
tags, so using this as an opportunity to replace Boost.Regex with std::regex
.
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.
Nice!
@@ -27,7 +26,7 @@ BOOST_AUTO_TEST_CASE(test_json_linestring) | |||
const auto coords = geom.values["coordinates"].get<util::json::Array>().values; | |||
BOOST_CHECK_EQUAL(coords.size(), 3); // array of three location arrays | |||
|
|||
for (const auto each : coords) | |||
for (const auto &each : coords) |
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.
Unit test changes are due to compiler errors from updated macOS clang.
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.
This crashes clang?
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.
Running make tests
with clang 12
error: loop variable 'each' creates a copy from type 'const mapbox::util::variant<osrm::util::json::String, osrm::util::json::Number, mapbox::util::recursive_wrapperosrm::util::json::Object, mapbox::util::recursive_wrapperosrm::util::json::Array, osrm::util::json::True, osrm::util::json::False, osrm::util::json::Null>' [-Werror,-Wrange-loop-construct]
for (const auto each : coords)
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.
Ah I see -Werror
strikes again.
93e5cc8
to
4784e43
Compare
It looks like Github Actions makes each job have a status check, rather than the action as a whole. This would be a problem if we want checks to be required because any change to the job matrix would break the required list. I think a solution is to have a no-op job that depends on all other jobs succeeding, and make this the only required check. That way we get required stability as the jobs evolve. |
15a910a
to
415bd81
Compare
Added a |
@danpat any thoughts on this? |
Added myself as reviewer, I'll take a look Friday. |
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.
Looks great, thanks for doing this. I think we can also trim the matrix a bit, there is little sense in supporting the older GCC from 4-5 years ago.
@@ -244,14 +242,15 @@ bool RestrictionParser::ShouldIgnoreRestriction(const std::string &except_tag_st | |||
|
|||
// Be warned, this is quadratic work here, but we assume that | |||
// only a few exceptions are actually defined. | |||
std::vector<std::string> exceptions; | |||
boost::algorithm::split_regex(exceptions, except_tag_string, boost::regex("[;][ ]*")); | |||
const std::regex delimiter_re("[;][ ]*"); |
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.
Nice!
@@ -27,7 +26,7 @@ BOOST_AUTO_TEST_CASE(test_json_linestring) | |||
const auto coords = geom.values["coordinates"].get<util::json::Array>().values; | |||
BOOST_CHECK_EQUAL(coords.size(), 3); // array of three location arrays | |||
|
|||
for (const auto each : coords) | |||
for (const auto &each : coords) |
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.
This crashes clang?
@@ -184,7 +184,7 @@ BOOST_AUTO_TEST_CASE(test_match_fb_serialization) | |||
const auto matchings = fb->routes(); | |||
const auto &number_of_matchings = matchings->size(); | |||
|
|||
for (const auto &waypoint : *waypoints) | |||
for (const auto waypoint : *waypoints) |
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.
Also clang-related?
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.
Yes, similar errors to above: https://github.com/mjjbell/osrm-backend/runs/2957246502?check_suite_focus=true#step:15:2784
error: loop variable 'destination' is always a copy because the range of type 'const flatbuffers::Vector<flatbuffers::Offsetosrm::engine::api::fbresult::Waypoint >' does not return a reference [-Werror,-Wrange-loop-analysis]
for (const auto &destination : *destinations_array)
^
/Users/runner/work/osrm-backend/osrm-backend/unit_tests/library/table.cpp:335:10: note: use non-reference type 'const osrm::engine::api::fbresult::Waypoint *'
for (const auto &destination : *destinations_array)
CLANG_VERSION: 5.0.0 | ||
ENABLE_MASON: ON | ||
|
||
- name: gcc-9-release |
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 think we can simplify the build matrix a bit and deprecate the older GCCs.
Thanks for the review @TheMarex! |
Replace Travis for continuous integration with Github Actions. The Github Actions pipeline is functionally equivalent, with all the same build permutations supported. Whilst the Github Actions offering is broadly equivalent to Travis, a few changes have been made as part of the migration. - The 'core' and 'optional' Travis stages have been consolidated into one build matrix. This is due to the current inability in Github Actions to share build steps between jobs, so this avoids having to duplicate the steps. Optional stage jobs will now run in parallel with core jobs, but they still remain optional in the sense that they don't fail the build. - A number of existing Github Action plugins are used to replace functionality provided by Travis or other tools: Node setup, caching, Codecov, publishing release artifacts. - Linux builds are updated to build on Ubuntu 18.04. MacOS builds are updated to run on 10.15. Similar to the Travis Xenial upgrade attempt, some changes are required due to underlying platform and compiler upgrades. This means some Node 10 toolchains will no longer be supported. Whilst there is opportunity to upgrade some dependencies and make the CI steps more idiomatic, I've left this for future changes and just focussed on functional replication.
d42cfa6
to
c8e35b3
Compare
@TheMarex would you be able to disable Travis CI as a required check? I believe only repo owners have the privileges needed. It's configured in the Settings page: https://docs.github.com/en/github/administering-a-repository/defining-the-mergeability-of-pull-requests/managing-a-branch-protection-rule The |
@mjjbell Done. I'll merge this now to enable the required |
Issue
This PR replaces Travis for continuous integration with Github Actions.
The Github Actions pipeline is functionally equivalent, with all the same build permutations supported. Whilst the Github Actions offering is broadly equivalent to Travis, a few changes have been made as part of the migration.
The
core
andoptional
Travis stages have been consolidated into one build matrix. This is due to the current inability inGithub Actions to share build steps between jobs, so this avoids having to duplicate the steps.
Optional stage jobs will now run in parallel with core jobs, but they still remain optional in the sense that they don't fail the build.
A number of existing Github Action plugins are used to replace functionality provided by Travis or other tools:
Linux builds are updated to build on
Ubuntu 18.04
. MacOS builds are updated to run on10.15
.Similar to the Travis Xenial upgrade attempt, some changes are required due to underlying platform and compiler upgrades. This means some Node 10 toolchains will no longer be supported.
Whilst there is opportunity to upgrade build dependencies and make the CI steps more idiomatic, I've left this for future changes and just focussed on functional replication.
Tasklist
Requirements / Relations
Closes #6056