Replies: 1 comment 3 replies
-
Yes, tests are listed and arranged manually in .circleci/config.yml and that is to fine-tune order and dependency of tests, and that is to optimise CI build times.
A 'closing' job making up the fan-in workflow seems like a good idea, assuming it would be no-op for already built tests and will only do any work for tests which are not explicitly listed indeed.
I'm quite sure there is any such solution to be expressed in YAML and a proper scripting would be required. The
I can't recall why the Ruby image is used. It's been there since 2018, so possibly it was a hacky way to get an image with C++ toolset. I don't see why those images shouldn't be upgraded. |
Beta Was this translation helpful? Give feedback.
-
Following this PR #1153 I have a couple of questions I want to ask regarding CircleCI.
algorithms/closest_points
,algorithms/convex_hull
. Supposedly, this is not intentional, this has to do with the manual assigning of tests to ci jobs. Should we add a job (that requires all other jobs to finish) that contain all tests e.g. a jobalgorithms
that executes all tests on algorithms after finishing jobs likealgorithms_area
so all missing (an possible newly added) algorithms are tested? Otherwise, we have to manually add the missing tests and update the script every time we create a new test directory. Since, I am not ayaml
expert there could be probably a more delicate solution to this...circleci/ruby:2.3
tocimg/ruby:2.3.0
or even to some base ubuntu image (do we use Ruby at all?). Currently, these are some tests failing due to some debian stretch repositories missing. This could be fixed in current image but why not upgrading to a newer one? Finally, if we move to a newer image we should probably still test our suite with gcc-6 see this discussion.I am willing to implement any changes/fixes but I need your feedback @awulkiew @barendgehrels @mloskot
Beta Was this translation helpful? Give feedback.
All reactions