docs(.github/release): describe performance benchmarking steps

[mxinden]

Document the steps required to test an upcoming go-libp2p release using the https://github.com/libp2p/test-plans/blob/master/perf/ libp2p performance benchmark tooling.

Document the follow-up steps required once a release is cut.

[marten-seemann]

This feels kind of heavy. Any chance we can add this to the uCI release workflow?

[mxinden]

Off the top of my head I can think of the following automation:

1. On creation of a new release in libp2p/go-libp2p
   1. Checkout https://github.com/libp2p/test-plans/
   2. Copy the most recent go-libp2p version folder in https://github.com/libp2p/test-plans/tree/master/perf/impl/go-libp2p
   3. Run go get -u ... to update to the to-be-tagged-as-release go-libp2p commit.
   4. Commit the changes, push them as a new branch to libp2p/test-plans and create a pull request.
   5. Trigger the perf GitHub Action on https://github.com/libp2p/test-plans/ with the above created branch.
   6. Post a comment on the pull request pointing users to https://observablehq.com/@libp2p-workspace/performance-dashboard?branch=<LIBP2P-TEST-PANS-BRANCH-NAME>

@galargh what do you think of the above? Any suggestions? Also would you be interested and have capacity to help?

@marten-seemann in case of a breaking change in go-libp2p you would still want to manually update the go-libp2p perf protocol implementation in libp2p/test-plans. Though this is not a blocker for any automation here. E.g. one could have the libp2p/test-plans pull request creation be automated and then only require the final touches to the pull request to be manual.

[mxinden]

Friendly ping @galargh. Any thoughts on the above?

[galargh]

I quickly put together how something like this could look like - libp2p/test-plans#256.

[marten-seemann]

Can this be triggered automatically?

[p-shahi]

I think we can trigger this when we add a comment in the pull request per https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#discussion_comment

For example commenting /perf in a PR would trigger the workflow. My original thought was to use a label but we might need to trigger the workflow multiple times in one PR. I'm down to investigate this to free up @mxinden (unless you'd like to take it up Max)

[mxinden]

My original thought was to use a label but we might need to trigger the workflow multiple times in one PR.

👍 preference for comment vs label for that reason.

[marten-seemann]

We might be able to ask IPDX for some help on some of the GHA suggestions here, but I'd first like to see what actually makes sense for us.

[BigLep]

General thought: before automation, lets do the manual steps to work out the kinks. Automation can come after it's proven out.

[marten-seemann]

@BigLep In general I agree, but this is adding 5 additional steps to every release. We've been working very hard to make our releases easy and smooth, so that we can release more frequently. I'm not saying we need to automate everything at this point, but what's being proposed here feels too heavy.

I'm also worried that once this PR is merged, it will ultimately become the go-libp2p maintainer's responsibility to create this automation.

[mxinden]

Closing here. With libp2p/test-plans#256 releases are automatically added. I don't think we need to document merging the automatically created pull request on libp2p/test-plans here.

Thank you @galargh for making this happen!