-
Notifications
You must be signed in to change notification settings - Fork 1.6k
ci: remove check-runtime job #5859
Conversation
|
We should keep this test and only remove it from non release branches and especially master. It is good to have the check on the release branches since we have it. I would prefer how it is done in #5858 Nowadays, the version in master should be bumped to the same version that we just released. I don't think it is a good idea to use a bigger runtime |
An issue mentioned in the description (only relevant for the native runtime):
So once we release 9270, the master should be bumped to 9280 (or, alternatively, master should be permanently on 99..99).
We could keep it for release branches, but then we won't see this check on PRs on github to release branches. Would it still be useful this way? I guess this is more of a question for release engineers. If we keep this check on PRs, then the release engineering team should bump the spec_version on master. Otherwise, as soon as the release is done, all PRs turn red, although they haven't changed anything. This is very annoying. |
|
I think we should just remove it. If someone wants it for the release branch or whatever, it can come back. However, each release we have this test failing for multiple days and it is just annoying! Anyone knows why the stable job didn't return any status? Is it maybe depending somehow on this check-runtime check? |
* master: Update RequestResponseConfig interface to match substrate (#5849)
My bad, should be fixed now. #5858 now also disables it for PRs, so it comes down to whether release engineers find this check being run on release branch (but not PRs to it) useful or not |
Alternative to #5858.
See #5858 (comment) for justification.
The original purpose of the check was to ensure we bump the spec_version on releases properly based on what's changed in master. Our current release process bumps it always, making this check obsolete.
One downside I can think of is a potential of getting "state root mismatch" when running e.g. burn-in from master.
To avoid that, we could:
spec_versionin master to some different value (e.g. 999999) than in release branchesspec_versionbump in master a part of the release process: Update release issue template #4268