Reverts part of commit 2539bd9 while keeping the intention of it:
To avoid duplicate CI runs when making and updating a PR.
Disabling `push` means we cannot push to a branch and see the CI results
directly without making a PR, which some of us use. There are many situations
where this is useful, and "[WIP]" PRs are not appropriate for all.
Disabling `pull_request` has a similar effect, removing duplicate CI.
It is known that `pull_request` _is_ needed when a third party sends a
PR (because it's not committed to the repo yet). But this is rare at the
moment, and there's a workaround: A committer can push the third party change
to a branch, triggering CI.
So re-enable `push`, disable `pull_request`, and we'll see if the latter
missing causes problems in practice. Won't know until we try it.
Note: This might be interim until `workflow_dispatch` is working better.
Perhaps that needs more configuration. Currently, `workflow_dispatch` is kind
of useless for CI tests, because it doesn't result in any CI indicator
associated with a commit or branch. Even the actions page doesn't show the
name of the branch, just a less-than-useful generic "CI" for these actions.
Signed-off-by: Jamie Lokier <jamie@shareable.org>
Files underneath `hive_integration` are not used to build anything,
so don't trigger CI when these files change.
Most of them are manually copied into Hive `hive/clients/nimbus`.
The rest are instructions and a standalone helper program not used by CI.
Signed-off-by: Jamie Lokier <jamie@shareable.org>
The CI takes a long time (sometimes hours) and shouldn't hold up
documentation-only commits. We may also find CI for other changes starts
faster, if we're not using up as many credits. When we process documentation
into something nicer (like `nimbus.guide`) we'll need to revisit this.
Syntax from [example ignoring paths](https://docs.github.com/en/actions/reference/workflow-syntax-for-github-actions#example-ignoring-paths).
Signed-off-by: Jamie Lokier <jamie@shareable.org>
why:
vm2 enabled by ENABLE_VM2=1 behaves as vm without ENABLE_EVMC=1 until
it doesn't in some future fatch set. this leaves some wiggle room
to work on a vm copy without degrading the original implementation.
details:
+ additional make flag ENABLE_VM2=1 (or ENABLE_VM2=0 to explicitely disable)
+ when both flags ENABLE_EVMC=1 and ENABLE_VM2=1 are present, the former
flag ENABLE_EVMC=1 takes precedence, this is implemented at the NIM
compiler level for -d:evmc_enabled and -d:vm2_enabled
Jamie Lokier
Ștefan Talpalaru
jangko
Jordan Hrycaj