Improving image publication workflow

Nodes Duniter-v2s
1

@HugoTrentesaux I think the docker image published with tag runtime-401 and as current latest doen’t have the correct bootnodes.

I’ve just migrated my smith node to a new server, and with latest image it didn’t start correctly:

2023-03-19 13:40:37 Running JSON-RPC HTTP server: addr=0.0.0.0:9933, allowed origins=None
2023-03-19 13:40:37 Running JSON-RPC WS server: addr=0.0.0.0:9944, allowed origins=None
2023-03-19 13:40:37 ***** Duniter has fully started *****
2023-03-19 13:40:38 💔 The bootnode you want to connect to at `/dns/gdev.p2p.legal/tcp/30334/p2p/12D3KooW9v5WsP38qU1kmafvA4CDw2vzYnFoWtdUqwonZtJK597r` provided a different peer ID `12D3KooWMYJzk1FfBZjEAuEvwUnH2Luj5Bq4ouLX1tgZBPpFegaB` than the one you expect `12D3KooW9v5WsP38qU1kmafvA4CDw2vzYnFoWtdUqwonZtJK597r`.
2023-03-19 13:40:38 💔 The bootnode you want to connect to at `/dns/gdev.p2p.legal/tcp/30334/p2p/12D3KooW9v5WsP38qU1kmafvA4CDw2vzYnFoWtdUqwonZtJK597r` provided a different peer ID `12D3KooWMYJzk1FfBZjEAuEvwUnH2Luj5Bq4ouLX1tgZBPpFegaB` than the one you expect `12D3KooW9v5WsP38qU1kmafvA4CDw2vzYnFoWtdUqwonZtJK597r`.
2023-03-19 13:40:38 💔 The bootnode you want to connect to at `/dns/gdev.p2p.legal/tcp/30334/p2p/12D3KooW9v5WsP38qU1kmafvA4CDw2vzYnFoWtdUqwonZtJK597r` provided a different peer ID `12D3KooWMYJzk1FfBZjEAuEvwUnH2Luj5Bq4ouLX1tgZBPpFegaB` than the one you expect `12D3KooW9v5WsP38qU1kmafvA4CDw2vzYnFoWtdUqwonZtJK597r`.                                                                                                            
2023-03-19 13:40:40 💔 The bootnode you want to connect to at `/dns/gdev.p2p.legal/tcp/30334/p2p/12D3KooW9v5WsP38qU1kmafvA4CDw2vzYnFoWtdUqwonZtJK597r` provided a different peer ID `12D3KooWMYJzk1FfBZjEAuEvwUnH2Luj5Bq4ouLX1tgZBPpFegaB` than the one you expect `12D3KooW9v5WsP38qU1kmafvA4CDw2vzYnFoWtdUqwonZtJK597r`.
2023-03-19 13:40:42 💤 Idle (0 peers), best: #1360868 (0x9090…64a1), finalized #1360866 (0x61ce…c1c7), ⬇ 0.2kiB/s ⬆ 0.2kiB/s

I had to use tag v0.4.1 for it to start correctly.

2

Even with ĞDev5 bootnodes, a Duniter node with runtime-401 embeded in its chainspecs will refuse to connect to ĞDev5 network because it would not share the same chainspec. That’s part of the reason why I do not want to use latest keyword without the network that the image targets (due to chainspecs, bootnodes, code substitutes…).

I’m not sure about what you are trying to achieve, but I feel like you are mixing things up.

[edit] sorry I did mix things up, I put the tag v0.4.1 on the release/hugo-chainspec-gdev5, so this one is valid. But I also forgot to commit the Cargo.lock so the version number on this image is not good.

3

I just wish we could tell any newcomer “just use the latest image”.

4

What do you expect newcomers to connect to? ĞDev I guess? So we should prevent the CI to publish a latest tag when it is not on a branch with current ĞDev’s chainspecs.

5

Obviously. I can’t see any alternative today actually.

Yes, we need to rethink our git workflow.

6

I moved these messages from the original thread about runtime-401 for readability in the future.

7

Part of the discussion about how to improve the image publication workflow happened in this thread: Release new image with ĞDev5 chainspecs

If I try to summarise :

  • we have to make sure that the “latest” label connects to current ĞDev network
  • we should refactor the CI to only publish images when wanted, and with correct tag
  • in the future, we could also have “gtest” and “g1” labels that connect to the respective network

We also have to define how we will be naming Duniter client versions. For example, right now, the only version labeled v0.4.1 is available in image duniter/duniter-v2s:sha-2be3f534.

2 Likes