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.
The punish test needs re-work due to the fact that Alice runs continuously
Currently focusing on the CLI (Bob), so we can re-introduce this test
once we want to ensure that nectar (Alice) punishes.
The test do not work without acks as we stop the event loop as soon
as a message is considered as "sent" when actually the event loop
and swarm may not have yet sent the message.
The ack allow to avoid this issue as the message was considered "sent"
only once the other party sent a response. However, the ack brings
other issue so a review needs to be done to select the appropriate
solution.
