Prepare main to become new default branch

[thanethomson]

This PR aims to sync the entire .github folder in main with that in master, updating the configuration for the new repo strategy.

One minor update to the Makefile was necessary in order to keep the tests split into groups, and some updates to some YAML files were necessary to get the linter to pass.

While I was at it, I've now updated the various issue/PR templates to better reflect our current workflow. Please let me know whether those updates seem reasonable. Some of the main changes there:

• Deleted .github/auto-comment.yml - doesn't seem like it was being used
• .github/ISSUE_TEMPLATE/{proposal,feature-request}.md - removed the #### For Admin Use section. Doesn't look like we really pay attention to it?
• .github/ISSUE_TEMPLATE/config.yml - hopefully I've configured this correctly (as per the GitHub docs).
• .github/ISSUE_TEMPLATE/*.md - updated the instructions in the comments to redirect users to the discussions section of the repo if they want to ask questions instead of logging issues.

[tychoish]

I don't know that there's any benefit in retaining these results, unless we have a plan to use them

[thanethomson]

What was the reasoning in having this in the first place?

[mark-rushakoff]

I think it makes sense to keep the crashers for 3 days -- if we are notified on Friday afternoon, we have an opportunity to review on Monday.

But off the top of my head, I don't know what the suppressions are, so I can't speak to why they should or should not be archived.

[tychoish]

I'm not sure. As far as I know the fuzz tests are basically useless, (e.g. they've never caught a bug in the last 18 months, as far as I know, aside from sometimes unexpectedly breaking compile, in silly but legitimate ways.)

[tychoish]

we should make sure that the number of splits here (6) are the right number of splits given the runtime of the tests and overhead.

[thanethomson]

How do we do that?

[tychoish]

Look at the runtime of the tests in the patch, and make sure that they're more or less balanced, I think. It's reasonably impressionistic. The way this all works is that it takes a sorted list of all of the packages that have tests and splits them, but number of tests and test runtimes in CI don't split along the same lines, so you could have one group that takes 10 minutes and 5 that take 2, and in that case, you don't actually get any responsiveness by having more splits, because the long poll is in one test.

We always used to have 4 splits, and we upped it to 6 when the tests were more flaky because it meant when you restarted the tests (to be able to merge something) you'd be able to see the failure more easily and potentially reduce the chance that more tests would flake on the restart.

[thanethomson]

for i in {0..5}; do /usr/bin/time -f "Test 0$i: %E" make test-group-0$i NUM_SPLIT=6; done
Test 00: 0:23.59
Test 01: 0:08.11
Test 02: 0:04.93
Test 03: 2:00.23
Test 04: 0:18.79
Test 05: 0:41.22

I think this seems reasonable?

[creachadair]

Maybe this is fine, but are these changes actually in the v0.34 line? This didn't seem to be related to the CI parts of the change offhand.

[thanethomson]

These fixes are just to get the linter to pass. I also went and checked the response schemas against the structs on the main branch and it seems there were a few minor inconsistencies there, so I fixed the schema where it was incorrect.

[creachadair]

Are these really no longer relevant?

[thanethomson]

It seems as though these were removed in #6684. I'll revert this for now until we re-apply that patch.

[thanethomson]

Actually, these tests were moved to the build workflow.

[mark-rushakoff]

Overall LGTM, but I'll leave approval to those more familiar with the previous CI implementations. Left a few comments on things that stood out to me.

[mark-rushakoff]

Fuzzing is built in to go1.18, so we should prefer the tooling built into the toolchain. I think that is fine to wait for a later PR, though.

[thanethomson]

I think this was implemented later on toward v0.35/v0.36. We can look at porting that work at some point.

[mark-rushakoff]

I think it makes sense to keep the crashers for 3 days -- if we are notified on Friday afternoon, we have an opportunity to review on Monday.

But off the top of my head, I don't know what the suppressions are, so I can't speak to why they should or should not be archived.

[mark-rushakoff]

It would be nice to mention how to run this locally. (I think it's just make lint?)

[thanethomson]

Yeah, it's just make lint. I've now added this to the end of the comment.

[tychoish]

I think the deletion of the minnet-kubernetes directory is probably fine, but I'm not sure it's in scope for the rest of this PR

[tychoish]

it's potentially a bit confusing to have duplication between this and the full team.

[thanethomson]

How so?

[tychoish]

should the -2 here also drop?

[thanethomson]

Not sure. This is how it is on master:

tendermint/.github/workflows/e2e-nightly-master.yml

Line 43 in d433ebe

e2e-nightly-fail-2:

[thanethomson]

Removed it. It seems redundant.

[tychoish]

I kind of think that we shouldn't change the linter config on the branch.

[thanethomson]

I'm not changing it, I'm just sync'ing with master. See

tendermint/.golangci.yml

Line 29 in d433ebe

- misspell

[tychoish]

I don't think we should add this without the corresponding implementation.

[thanethomson]

It's already on main (i.e. in v0.34):

tendermint/rpc/core/types/responses.go

Line 209 in 4309f54

type ResultBlockSearch struct {

While fixing the linting issues in the OpenAPI config, I discovered that there were a bunch of things that were missing/incorrect. So I've fixed them here to match the code on main.

See

tendermint/rpc/openapi/openapi.yaml

Line 1067 in 4309f54

$ref: "#/components/schemas/BlockSearchResponse"

on main for example, where there's no definition of BlockSearchResponse in the OpenAPI config.

[thanethomson]

I think the deletion of the minnet-kubernetes directory is probably fine, but I'm not sure it's in scope for the rest of this PR

To get the YAML linting to pass I either had to fix all of the k8s scripts, or just delete them, so I deleted them (since this is what happened to them on master).