Continuous Integration Cycles

When working on Yorick, it's possible to create "CI cycles".

Dependency Architecture of ykrustc.

There are two main repos for Yorick:

• ykrustc: the compiler.
• yk: the other stuff, including ykpack.

ykpack is the library that deals with SIR serialisation and de-serialisation. The compiler uses it to encode SIR into an ELF section, and the JIT runtime uses it to decode the section.

This leads to a problem: if you change the format of the SIR (change the serialised types in any way that would change the binary representation once serialised), then CI cannot succeed. This is because the yk repo needs to be built with a ykrustc which uses the new ykpack, but yk itself contains the new ykpack.

How do we Break the Cycle?

We break the cycle using a 3-PR model as follows:

• The reviewer conducts a review of the changes to the yk repo first. Get it ready for merge, but don't merge it yet.
• The PR author then adds a separate commit to ykrustc which overrides the dependency on ykpack, pointing instead to the git revision containing the breaking changes. E.g.:

[dependencies]                                                                                                                                                 
...                                                                                                             
#ykpack = { git = "https://github.com/softdevteam/yk" }                                                                                                        
ykpack = { git = "https://github.com/vext01/yk", rev = "<git hash>" }

• The reviewer then reviews the ykrustc change and invokes bors to do the merge.
• Once this is merged, the yk change can be merged.
• Once that is merged, a new PR can be raised which simply backs out the dependency override in ykrustc.