1. Split up image::Monero into Monerod and MoneroWalletRpc
2. Don't use `bash` to run the internal command. Instead we disable
the entrypoint script as per https://github.com/XMRto/monero#raw-commands
3. Remove the start up delay by listening for the correct log message.
To make this more resilient, we make the log level NOT configurable and
instead always log verbosely.
412: Bump actions/setup-python from v2.2.1 to v2.2.2 r=thomaseizinger a=dependabot[bot]
Bumps [actions/setup-python](https://github.com/actions/setup-python) from v2.2.1 to v2.2.2.
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a href="https://github.com/actions/setup-python/releases">actions/setup-python's releases</a>.</em></p>
<blockquote>
<h2>v2.2.2</h2>
<p>Address PyPy installation issues on Windows: <a href="https://github-redirect.dependabot.com/actions/setup-python/issues/196">actions/setup-python#196</a></p>
</blockquote>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a href="dc73133d4d"><code>dc73133</code></a> Fix PyPy installation on Windows to adopt new parameters format (<a href="https://github-redirect.dependabot.com/actions/setup-python/issues/201">#201</a>)</li>
<li><a href="a1121449a2"><code>a112144</code></a> Add on: pull_request trigger to CodeQL workflow (<a href="https://github-redirect.dependabot.com/actions/setup-python/issues/180">#180</a>)</li>
<li><a href="66319ca9fa"><code>66319ca</code></a> Use quotes around Python versions in README (<a href="https://github-redirect.dependabot.com/actions/setup-python/issues/175">#175</a>)</li>
<li>See full diff in <a href="https://github.com/actions/setup-python/compare/v2.2.1...dc73133d4da04e56a135ae2246682783cc7c7cb6">compare view</a></li>
</ul>
</details>
<br />
Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`.
[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)
---
<details>
<summary>Dependabot commands and options</summary>
<br />
You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot squash and merge` will squash and merge this PR after your CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge and block automerging
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
- `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
- `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
- `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
</details>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
- Swap-id is exchanged during execution setup. CLI (Bob) sends the swap-id to be used in his first message.
- Transfer poof and encryption signature messages include the swap-id so it can be properly associated with the correct swap.
- ASB: Encryption signatures are associated with swaps by swap-id, not peer-id.
- ASB: Transfer proofs are still associated to peer-ids (because they have to be sent to the respective peer), but the ASB can buffer multiple
- CLI: Incoming transfer proofs are checked for matching swap-id. If a transfer proof with a different swap-id than the current executing swap is received it will be ignored. We can change this to saving into the database.
Includes concurrent swap tests with the same Bob.
- One test that pauses and starts an additional swap after the transfer proof was received. Results in both swaps being redeemed after resuming the first swap.
- One test that pauses and starts an additional swap before the transfer proof is sent (just after BTC locked). Results in the second swap redeeming and the first swap being refunded (because the transfer proof on Bob's side is lost). Once we store transfer proofs that we receive during executing a different swap into the database both swaps should redeem.
Note that the monero harness was adapted to allow creating wallets with multiple outputs, which is needed for Alice.
Whenever a release branch - that is a branch starting with `release/` -
is merged into master, we create a new GitHub release based on the
version number in the branch name.
Similarly to the preview release, we extract the relevant section of
the changelog and make it the release body.
Drafting a new release can be quite involved. One has to update the
changelog correctly, bump the versions in the manifest files, commit
everything and raise a PR.
This workflow does all of that for you at the click of a button!
The request-response behaviour that is used for sending the transfer
proof actually has a functionality for buffering a message if we
are currently not connected. However, the request-response behaviour
also emits a dial attempt and **drops** all buffered messages if this
dial attempt fails. For us, the dial attempt will very likely always
fail because Bob is very likely behind NAT and we have to wait for
him to reconnect to us.
To mitigate this, we build our own buffer within the EventLoop and
send transfer proofs as soon as we are connected again.
Resolves#348.
By default, GitHub uses the last commit message as the body text.
This can be a lot of text if the last commit was from dependabot.
Make the preview release more pleasant to look at by adding a
dedicated body.
Windows users may not have a tar extractor installed by default so 7z
was used to create a zip archive. I attempted to add the action names to
the strategy matrix so we dont need if statements to choose the
appropriate create release archive action but github did not like when
I passed a field under strategy.matrix.include into steps.uses.
tar was producing an archived that binary that was failing to execute on
developer machines. Since gtar is not available on windows or ubuntu,
the windows and ubuntu releases was removed.
256: Give GitHub some time to process the deletion of the release r=thomaseizinger a=thomaseizinger
Co-authored-by: Thomas Eizinger <thomas@eizinger.io>
This allows us to completely skip the "Install Rust" step in CI
because the rust-toolchain file completely describes what we need.
The first invocation of cargo will simply install all the required
components.
Additionally, we make all caches dependant on the version of Rust
that we require.
Usually, we can follow the rolling major tag (@v2) of actions.
However the recent release (2.1.4) is not yet included. See
https://github.com/actions/cache/issues/528 for more details.
We do want to depend on 2.1.4 because it contains a fix that allows
us to use the cache action MacOS. v2 also features better compression
and allows for multiple paths to be specified.
Building binaries and building tests results in different artifacts
inside the `target` directory. If we use distinct caches for these
commands, the caches are more useful because less code has to be
re-built.
