Since we ping our build/deploy container to rust:stretch, which pulls in the latest rust:stable
by default, our rustc will change under us when a new rust:stable is available, possibly changing the
output of our builds and making them noisier. They shouldn't _break_, but still,
it's good to know what changed when the build log 'suddenly' starts to look different.
It's possible that we might want to pin a version of rust or the upstream container
in the future and use a smart job similar to Dependabot to open a pull request
that will upgrade and test the new version of Rust before we merge it,
but since Rust stable versions are supposed to be, well, stable, this is
less of a concern than our cargo dependencies.
Fixes#146
* Migrate old workflow file
* Only build fuzzers on master
* Conditional branch matching on steps shouldn't be this hard
* Remove old workflow file
* Reorder the if and the uses
To see if putting the 'if' first will prevent the image that 'uses' references from being fetched
when the step doesn't actually run.
* Nope, that's a bug in GitHub Actions
* Wrong project name 🙃
* Remove standard Rust workflow, rename some steps
* Remove .travis.yml
* Remove .gitlab-ci.yml
* Increase container layer cache ttl to 12hours
* Add cloudbuild.yaml
* Add longer timeouts than the default 10 minutes.
* Parallel gcloud build action via cli
* gcloud auth is not master-only now
* See how gcloud Kaniko container layer caching does
Leave out the .cargo/ and target/ copies for now, break out 'cargo fetch' on its
own line because that's probably cachable.
* Fix some scripting
* Bah those layers are needed yet
* Comment out build job timeout
* Try this kaniko cache warmer and docker pre-pull
* Yaml is annoying
* Cache .cargo in separate Docker layer, streamline cloudbuild
* Fix COPY
* Ah, locally it was searching up the tree for another .toml
* Try 8 cores vs 32
* Revert "Try 8 cores vs 32"
This reverts commit 636e9668a7.
* Streamline workflow
* Fix workflow
* Remove defunct resolveer
* I think explicitly adding :latest is redundant for GCR
* Try image push to see if latest tag auto populates
* Move workspace members to have zebra- names.
This commit breaks the build because it doesn't update any of the Cargo.toml
files, but the advantage is that this commit is a simple git mv for ease of
review.
* Update Cargo.toml files to have new file paths.
This is a separate commit to the preceding commit for ease of review (so that
the preceding commit is a simple git mv).
* Update license and author metadata in workspace crates.
- ensure that the license field is set to GPL-3 for all GPL-3 licensed crates;
- ensure that the author field is set to "Zcash Foundation", responsible for maintenance;
- preserve the original authorship info in AUTHORS.md for human-readable history.
Updating the author field ensures that all of the machine systems that read
crate metadata list the ZF organization, not any single individual, as the
maintainer of the crate.
* Prefix all internal crate names with zebra-.
This does not move the directories containing these crates to also have zebra-
prefixes (for instance, zebra-chain instead of chain). I think that this would
be preferable, but because it's a `git mv`, it will be simple to do later and
leaving it out of this change makes it easier to see the renaming of all of the
internal modules.
* Remove git dependency from eth-secp256k1
* Avoid an error seemingly related to Deref coercions.
This code caused an overflow while evaluating type constraints. As best as I
can determine, the cause of the problem was something like so: the Rust
implementation of the Bitcoin-specific hash function used in the Bloom filter
doesn't operate on byte slices, but only on a `&mut R where R: Read`, so to
hash a byte slice, you need to create a mutable copy of the input slice which
can be consumed as a `Read` implementation by the hash function; the previous
version of this code created a slice copy using a `Deref` coercion instead of
`.clone()`, and when a tokio update added new trait impls, the type inference
for the `Deref` coercion exploded (somehow -- I'm not sure about the last
part?).
This commit avoids the problem by manually cloning the input slice.
All *net keys besides mainnet were using empty values, which ran into length issues.
* Clean up Dockerfile logging
* Use mainnet verification keys for all *nets
Resolves#12, #22
* This still fails inside containers (#3)
* Try to pass the optional fuzzer builds via signal for now (#4)
Otherwise wise the whole workflow is marked a failure, which it isn't, it just doesn't really support
'additional' actions.
Dimitris Apostolou
Deirdre Connolly
dependabot-preview[bot]
Henry de Valence
Deirdre Connolly
Taylor Hornby
Za Wilcox
dependabot-preview[bot]