As a technical maintainer of this library I need to ensure that proposed change does not break anything. Since elab-util is in the upstream's CI and there is a custom that when upstream breaks elab-util, it merges reaction first (and this breaks elab-util's CI), and the upstream merges the breaking change with green CI (it uses the main branch, so this can be done in a single day).
In such an upstream-reaction PRs there is a need for a simple but tiring work of checking the PR against the state of the compiler not at the main branch, but at the branch of the PR taken from the repository clone of the PR proposer. I fed up doing this, so I invented an automation for this.
So, I suggest to add an additional job to the CI, which performs usual CI checks of the lib, but in the different environment, namely, in the environment of the upstream compiler taken from the breaking PR to the upstream. Technically, if the title of elab-util's PR contains [ upstream ] and the body of the PR contains a link to an upstream PR in the form of URL or in the form of idris-lang/Idris2#<PR-number>, then an additional job enables and checks elab-util in a modified compiler version. The original job remains effectively unchanged.
Proposed checks duplicates calls to pack typecheck and pack test. I tried to merge both jobs to avoid it, but the solution was uglier than simple duplication, so I decided it to be so.
As a technical maintainer of this library I need to ensure that proposed change does not break anything. Since
elab-util
is in the upstream's CI and there is a custom that when upstream breakselab-util
, it merges reaction first (and this breakselab-util
's CI), and the upstream merges the breaking change with green CI (it uses themain
branch, so this can be done in a single day).In such an upstream-reaction PRs there is a need for a simple but tiring work of checking the PR against the state of the compiler not at the
main
branch, but at the branch of the PR taken from the repository clone of the PR proposer. I fed up doing this, so I invented an automation for this.So, I suggest to add an additional job to the CI, which performs usual CI checks of the lib, but in the different environment, namely, in the environment of the upstream compiler taken from the breaking PR to the upstream. Technically, if the title of
elab-util
's PR contains[ upstream ]
and the body of the PR contains a link to an upstream PR in the form of URL or in the form ofidris-lang/Idris2#<PR-number>
, then an additional job enables and checkselab-util
in a modified compiler version. The original job remains effectively unchanged.Proposed checks duplicates calls to
pack typecheck
andpack test
. I tried to merge both jobs to avoid it, but the solution was uglier than simple duplication, so I decided it to be so.@stefan-hoeck, what do you think?