do not optimize docusaurus build

[pgrange]

The Documentation step was taking several minutes to optimize a web-site we will, most of the time, never publish. And, also, it was doing it twice sometimes.

So we do not generate documentation twice anymore. Also, we only generate optimized documentation for branch master and release. For all the other branches, we keep building the docusaurus stuff but only for sanity check so we don't optimize and we don't upload the artifact either.

To check that this P.R. did not break with the Publish Docs workflow, one can check this run which contains an artifact that you can download to check locally (spoiler alert: it still works): https://github.com/input-output-hk/hydra/actions/runs/5047620832

• saves around 5 minutes
• Introduces a new TODO to remove backward compatibility C.I. code in the future

[github-actions]

Test Results

318 tests  +11   312 ✔️ +11   21m 49s ⏱️ +12s
108 suites +  4       6 💤 ±  0 
    6 files   +  1       0 ❌ ±  0 

Results for commit 8c18875. ± Comparison against base commit 2365ffd.

♻️ This comment has been updated with latest results.

[pgrange]

@ffakenz could you double check what I changed here?

I'm considering that, either we're on master or not so I don't generate documentation twice, once for stable and once for unstable.

But, honestly, I have no idea what impact it may have in the way we publish our doc. Did I break something?

[github-actions]

Transactions Costs

Sizes and execution budgets for Hydra protocol transactions. Note that unlisted parameters are currently using arbitrary values and results are not fully deterministic and comparable to previous runs.

Metadata
Generated at	2023-05-24 09:51:46.50305403 UTC
Max. memory units	14000000
Max. CPU units	10000000000
Max. tx size (kB)	16384

Script summary

Name	Hash	Size (Bytes)
νInitial	e5cc20df4a2216e706b3d00b59fbb15a7cf12dbd28d271d4a8cf6d04	4336
νCommit	47c102d5f95a0648b4065f2b8bff59d3e34536a82ee7b0d42df73123	2124
νHead	9fe3a5c4d826f9475368e1e24c15bf22f4df19893cce2689d3c0564a	9492
μHead	7bec671467e923281c92e94257931913be106e217270a7b97076cb9b*	4148

• The minting policy hash is only usable for comparison. As the script is parameterized, the actual script is unique per Head.

Cost of Init Transaction

Parties	Tx size	% max Mem	% max CPU	Min fee ₳
1	4741	12.92	5.06	0.50
2	4944	15.24	5.93	0.53
3	5151	19.82	7.74	0.59
5	5562	24.34	9.44	0.66
10	6586	36.52	14.04	0.84
37	12124	97.41	36.90	1.74

Cost of Commit Transaction

Currently only one UTxO per commit allowed (this is about to change soon)

UTxO	Tx size	% max Mem	% max CPU	Min fee ₳
1	603	15.29	5.93	0.34

Cost of CollectCom Transaction

Parties	UTxO (bytes)	Tx size	% max Mem	% max CPU	Min fee ₳
1	57	825	27.72	10.80	0.49
2	114	1139	43.16	16.96	0.67
3	171	1463	60.62	23.98	0.88
4	227	1792	81.88	32.54	1.13

Cost of Close Transaction

Parties	Tx size	% max Mem	% max CPU	Min fee ₳
1	639	18.88	8.43	0.39
2	805	19.98	9.56	0.42
3	969	21.37	10.82	0.44
5	1299	24.16	13.33	0.50
10	2124	31.13	19.62	0.64
50	8725	87.17	69.99	1.74

Cost of Contest Transaction

Parties	Tx size	% max Mem	% max CPU	Min fee ₳
1	675	24.77	10.64	0.46
2	842	26.06	11.84	0.48
3	995	28.20	13.38	0.52
5	1335	31.63	16.12	0.58
10	2161	40.20	22.97	0.74
44	7772	98.03	69.37	1.78

Cost of Abort Transaction

Some variation because of random mixture of still initial and already committed outputs.

Parties	Tx size	% max Mem	% max CPU	Min fee ₳
1	4857	22.19	9.33	0.61
2	5183	36.25	15.44	0.78
3	5504	53.24	22.87	0.99
4	5828	72.83	31.46	1.22
5	6149	95.12	41.22	1.49

Cost of FanOut Transaction

Involves spending head output and burning head tokens. Uses ada-only UTxO for better comparability.

Parties	UTxO	UTxO (bytes)	Tx size	% max Mem	% max CPU	Min fee ₳
5	0	0	4764	8.67	3.57	0.46
5	1	57	4800	10.06	4.39	0.47
5	5	285	4944	15.64	7.69	0.55
5	10	566	5122	22.61	11.82	0.64
5	20	1140	5485	36.57	20.08	0.83
5	30	1709	5846	50.53	28.34	1.02
5	40	2275	6197	64.49	36.60	1.21
5	50	2845	6561	78.46	44.87	1.40
5	65	3701	7104	99.42	57.28	1.68

[ch1bo]

The premise of this work is very much what I thought we fix about this workflow:

• keep sanity checking of docs separate from actually creating the website, effectively using the fastest, complete build for CI
• move the building of the website into the https://github.com/input-output-hk/hydra/actions/workflows/publish-docs.yaml workflow
  • not using artifacts, but just building it twice whenever we need it built
  • that is, push on master and push on release branches for example

Instead of trying to optimize a conceptionally fragile workflow, I would suggest to move to a more robust approach first and by that, eliminate slow CI by design?