Split workflows to facilitate CI restart in case of failing jobs #330
Conversation
|
I have no objection to splitting these up in principle. My concern about doing it purely by platform (macos vs ubuntu) is that it's not clear which file a specific job belongs to. For example, in order to find the client checks I have to know that we run those on ubuntu. As discussed in the past, it may happen that testing the full pipeline may happen to be easier to do on macos. |
This asymmetry between checks ran on a given platform is only due to the poor state of our CI. Normally if we claim support for a platform (as we do in the README: https://github.com/clearmatics/zeth#building-and-running-the-project) this must imply that we run all checks on this platform. We don't do that for now, but this will need to be done in the future (and issues related to the solc compiler - on macOS - and grpc - on linux - will need to be solved). I don't think the approach where we run all checks only on "the platform on which it is the easiest to do so" is what should be done in the long run. That's obviously what we do for now (because we don't have the bandwidth to do a polished CI...). So in the end state, |
I'm not sure we need to run all checks on all platforms to claim support. For example, do we need to run a solidity or python linter on all platforms? Or even the clang-format check?
OK. It would definitely be better if we could re-run individual jobs. TBH I hadn't really considered it enough of a problem to duplicate the configs (it's mainly a waste) but if it's super annoying then let's address it one way or another. How about we split the checks out into their own (It seems we are not using the the matrix to specify platforms yet anyway, so less of an issue to split these |
Ah. No I don't think running the linters etc should necessarily be done on all platforms to claim support (although that would be nice to make sure that the tooling we use is supported on the platforms we target -- or at very least document well potential compatibility issues for devs to avoid troubles when contributing -> this is very annoying if the CI fails for instance for a linting issue if you can't, as a dev, reproduce locally and use the adequate tool to fix the issue). My point is mostly that all tests (python, solidity, c++) and builds (DEBUG, RELEASE) are successful for all supported platforms (some of these are currently spread across several jobs running on different architectures, so we don't tests everything on all platforms).
Yes using a
So do I understand correctly that by "workflows would be related to the type" you suggest to move all checks like "linting checks" etc to the (generic/platform agnistic) |
So, what I'm suggesting is that we split into workflows of the form For now, this would be:
If GA later implements rerunning individual jobs, and our build commands converge across the platforms, the Later, I guess we might be able to add |
|
Sounds good, let's do that! |
4fe5271 to
3b05af4
Compare
3b05af4 to
93803b0
Compare
See: #320