New release version
Remove hhvm reference
Remove hhvm reference
# https://github.com/actions/virtual-environments/issues/2840
sudo apt-get remove -y '^dotnet-.*'
sudo apt-get remove -y 'php.*'
sudo apt-get remove -y azure-cli google-cloud-sdk hhvm google-chrome-stable firefox powershell mono-devel
sudo apt-get remove -y azure-cli google-cloud-sdk google-chrome-stable firefox powershell mono-devel
sudo apt-get autoremove -y
sudo apt-get clean
sudo rm -rf /usr/share/dotnet
1.35.4
1.35.5
I don't trust it. Compare these two runs: 1. https://github.com/input-output-hk/cardano-haskell-packages/actions/runs/4532746158/jobs/7984714895 2. https://github.com/input-output-hk/cardano-haskell-packages/actions/runs/4516172089/jobs/7954255360 The second is on the parent commit of the first, the commit itself is a no-op, and yet the derivations they build are not the same! Doing the same locally, I get a) a different derivation, but b) the same derivation for both. I conclude that what the CI is doing is questionable, the cache seems like the most likely source of pollution. I suspect whatever is causing this was also responsible for the no-op PR spending a lot of time building tons of stuff.
Co-authored-by: Sebastien Guillemot <[email protected]>
5018: Use ouroboros-network-0.3.0.2 and ouroboros-network-framework-0.2.0.1 r=dermetfan a=coot Co-authored-by: Marcin Szamotulski <[email protected]> Co-authored-by: Samuel Leathers <[email protected]>
Waiting for a day, at a pace of one block every 20 seconds would generate 4320 blocks which takes forever to be created and processes, even in IO sim. We don't really observe the issue now because we cheat in the way we generate the block. This commit helps preparing for a more realistic block generation.
Everyone collects after observing the last commit
That way, we try to get closer to an actual block production pattern.