diff --git a/.github/workflows/docs_tags.yaml b/.github/workflows/docs_tags.yaml
index 3495c05a16..35deaaa1f3 100644
--- a/.github/workflows/docs_tags.yaml
+++ b/.github/workflows/docs_tags.yaml
@@ -33,4 +33,4 @@ jobs:
git config --global user.email github-actions[bot]@users.noreply.github.com
- name: Build and deploy docs to gh-pages
run: |
- uv run mike deploy --update-aliases --push --remote origin ${{ github.ref_name }} latest
+ uv run mike deploy --push --remote origin ${{ github.ref_name }}
diff --git a/docs/dev/docs.md b/docs/dev/docs.md
index 002c326955..6934433a7b 100644
--- a/docs/dev/docs.md
+++ b/docs/dev/docs.md
@@ -47,16 +47,16 @@ The deployed versions of the docs managed via `mike` are kept in the [gh-pages](
### Aliases
-We currently use two aliases:
+We currently have two aliases (which both point to `main` as of [#998](https://github.com/ethereum/execution-spec-tests/pull/998)):
-- [`latest`](https://ethereum.github.io/execution-spec-tests/latest): the latest stable release.
+- [`latest`](https://ethereum.github.io/execution-spec-tests/latest): the current state of the main branch.
- [`development`](https://ethereum.github.io/execution-spec-tests/development): the current state of the main branch.
These aliases point to specific versions, as configured below. It's possible to share links containing either of these aliases or to specific versions, i.e, the following are all valid links:
- https://ethereum.github.io/execution-spec-tests/ (redirects to latest/main)
- https://ethereum.github.io/execution-spec-tests/latest (redirects to main)
-- https://ethereum.github.io/execution-spec-tests/development (redirects to tagged version)
+- https://ethereum.github.io/execution-spec-tests/development (redirects main)
- https://ethereum.github.io/execution-spec-tests/main
- https://ethereum.github.io/execution-spec-tests/v1.0.0
@@ -65,7 +65,7 @@ These aliases point to specific versions, as configured below. It's possible to
There are two workflows that automatically deploy updated/new versions of the docs:
| Workflow `yaml` File | What | When |
-|-----------------_____|------|------|
+|----------------------|------|------|
| `docs_main.yaml` | Update "main" version of docs | Push to 'main' branch, (e.g., on PR merge) |
| `docs_tags.yaml` | Deploy new version of docs; tag is used as version name | Upon creating a tag matching `v*` |
@@ -74,7 +74,7 @@ There are two workflows that automatically deploy updated/new versions of the do
Build a new version and deploy it to remote (this version will then show up in the version selector list):
```console
-uv run mike deploy --push v1.2.3
+uv run mike deploy -rebase --push v1.2.3
```
!!! note "Local deployment"
@@ -85,7 +85,7 @@ uv run mike deploy --push v1.2.3
Build, deploy and update the version an alias points to with:
```console
-uv run mike deploy --push --update-aliases v1.2.3 latest
+uv run mike deploy --rebase --push --update-aliases v1.2.3 latest
```
where `v1.2.3` indicates the version's name and `development` is the alias. This will overwrite the version if it already exists.
@@ -94,13 +94,13 @@ where `v1.2.3` indicates the version's name and `development` is the alias. This
"main" is just a version name (intended to reflect that it is build from the main branch). However, `mike` will build the docs site from the current local repository state (including local modifications). Therefore, make sure you're on the HEAD of the main branch before executing (unless you know what you're doing :wink:)!
```console
- uv run mike deploy --push main
+ uv run mike deploy --rebase --push main
```
If the alias accidentally go change:
```console
- uv run mike deploy --push --update-aliases main development
+ uv run mike deploy --rebase --push --update-aliases main development
```
### Viewing and Deleting Versions
diff --git a/docs/getting_started/overview.md b/docs/getting_started/overview.md
deleted file mode 100644
index 8277a8934d..0000000000
--- a/docs/getting_started/overview.md
+++ /dev/null
@@ -1,82 +0,0 @@
-# Execution Spec Tests
-
-
-
-@ethereum/execution-spec-tests is both a collection of test cases and a framework in Python to generate tests for Ethereum execution clients implemented.
-
-The framework collects and executes the test cases in order to generate _test fixtures_ (JSON) which can be consumed by any execution client to verify their implementation of [ethereum/execution-specs](https://github.com/ethereum/execution-specs). The fixtures, which define state transition and block tests, are generated by the framework using one of the `t8n` command-line tools that are provided by most execution clients, see below for an overview of the supported `t8n` tools.
-
-```mermaid
----
-title: Test Fixture Generation with execution-spec-tests
----
-flowchart LR
- style C stroke:#333,stroke-width:2px
- style D stroke:#333,stroke-width:2px
- style G stroke:#F9A825,stroke-width:2px
- style H stroke:#F9A825,stroke-width:2px
-
- subgraph ethereum/go-ethereum
- C[evm t8n
\nexternal executable]
- end
-
- subgraph ethereum/solidity
- D[solc
\nexternal executable]
- end
-
- subgraph ethereum/EIPs
- E(EIPS/EIP-*.md
\nSHA digest via Github API)
- end
-
- subgraph "ethereum/execution-spec-tests"
- A(./tests/**/*.py
\nPython Test Cases)
- B([$ fill ./tests/
\nPython Framework])
- end
-
- subgraph Test Fixture Consumers
- subgraph ethereum/hive
- G([$ hive ...
\nGo Test Framework])
- end
- H([Client executables])
- end
-
- C <-.-> B
- D <-.-> B
- A --> B
- E <-.-> |retrieve latest spec version\ncheck tested spec version| B
- B -->|output| F(./fixtures/**/*.json
\nJSON Test Fixtures)
- F -->|input| G
- F -->|input| H
-```
-
-The generated test fixtures can be used:
-
-1. Directly by client teams' test frameworks, and,
-2. In the integration tests executed in the @ethereum/hive framework.
-
-More information on how to use and download the [released test fixtures](https://github.com/ethereum/execution-spec-tests/releases) can be found [here](../consuming_tests/index.md).
-
-## Relationship to ethereum/tests
-
-This collection of tests is relatively new (test case development started Q4, 2022) and mainly targets recent and upcoming Ethereum specification changes. It does not replace, but rather complements the existing tests in [ethereum/tests](https://github.com/ethereum/tests).
-
-## Motivation
-
-The motivation to implement test cases in [ethereum/execution-spec-tests](https://github.com/ethereum/execution-spec-tests) is:
-
-1. To implement test cases as code and ensure that changes, due to spec changes, for example, can be easily made. Moreover, changes are easily understandable and available in version control.
-2. To avoid the 2-step approach often used in [ethereum/tests](https://github.com/ethereum/tests):
- 1. Code (often unavailable) -> Test case (YAML).
- 2. Test case (YAML) -> Fixtures (JSON).
-
-!!! success "Contributing"
- Contributions via [PR](https://github.com/ethereum/execution-spec-tests/pulls) are welcome!
-
-!!! bug "Reporting a Vulnerability"
-
- Care is required when adding PRs or issues for functionality that is live on Ethereum mainnet. Please report vulnerabilities and verify bounty eligibility via the [bug bounty program](https://bounty.ethereum.org).
-
- - **Please do not create a PR with a vulnerability visible.**
- - **Please do not file a public ticket mentioning the vulnerability.**
diff --git a/docs/getting_started/img/execution_spec_tests.png b/docs/img/execution_spec_tests.png
similarity index 100%
rename from docs/getting_started/img/execution_spec_tests.png
rename to docs/img/execution_spec_tests.png
diff --git a/docs/index.md b/docs/index.md
index b2f837024b..1e508a048c 100644
--- a/docs/index.md
+++ b/docs/index.md
@@ -1,11 +1,82 @@
-
-
-
-
If you are not redirected, click here.
- - +# Execution Spec Tests + + + +@ethereum/execution-spec-tests is both a collection of test cases and a framework in Python to generate tests for Ethereum execution clients implemented. + +The framework collects and executes the test cases in order to generate _test fixtures_ (JSON) which can be consumed by any execution client to verify their implementation of [ethereum/execution-specs](https://github.com/ethereum/execution-specs). The fixtures, which define state transition and block tests, are generated by the framework using one of the `t8n` command-line tools that are provided by most execution clients, see below for an overview of the supported `t8n` tools. + +```mermaid +--- +title: Test Fixture Generation with execution-spec-tests +--- +flowchart LR + style C stroke:#333,stroke-width:2px + style D stroke:#333,stroke-width:2px + style G stroke:#F9A825,stroke-width:2px + style H stroke:#F9A825,stroke-width:2px + + subgraph ethereum/go-ethereum + C[evm t8n
\nexternal executable]
+ end
+
+ subgraph ethereum/solidity
+ D[solc
\nexternal executable]
+ end
+
+ subgraph ethereum/EIPs
+ E(EIPS/EIP-*.md
\nSHA digest via Github API)
+ end
+
+ subgraph "ethereum/execution-spec-tests"
+ A(./tests/**/*.py
\nPython Test Cases)
+ B([$ fill ./tests/
\nPython Framework])
+ end
+
+ subgraph Test Fixture Consumers
+ subgraph ethereum/hive
+ G([$ hive ...
\nGo Test Framework])
+ end
+ H([Client executables])
+ end
+
+ C <-.-> B
+ D <-.-> B
+ A --> B
+ E <-.-> |retrieve latest spec version\ncheck tested spec version| B
+ B -->|output| F(./fixtures/**/*.json
\nJSON Test Fixtures)
+ F -->|input| G
+ F -->|input| H
+```
+
+The generated test fixtures can be used:
+
+1. Directly by client teams' test frameworks, and,
+2. In the integration tests executed in the @ethereum/hive framework.
+
+More information on how to use and download the [released test fixtures](https://github.com/ethereum/execution-spec-tests/releases) can be found [here](consuming_tests/index.md).
+
+## Relationship to ethereum/tests
+
+This collection of tests is relatively new (test case development started Q4, 2022) and mainly targets recent and upcoming Ethereum specification changes. It does not replace, but rather complements the existing tests in [ethereum/tests](https://github.com/ethereum/tests).
+
+## Motivation
+
+The motivation to implement test cases in [ethereum/execution-spec-tests](https://github.com/ethereum/execution-spec-tests) is:
+
+1. To implement test cases as code and ensure that changes, due to spec changes, for example, can be easily made. Moreover, changes are easily understandable and available in version control.
+2. To avoid the 2-step approach often used in [ethereum/tests](https://github.com/ethereum/tests):
+ 1. Code (often unavailable) -> Test case (YAML).
+ 2. Test case (YAML) -> Fixtures (JSON).
+
+!!! success "Contributing"
+ Contributions via [PR](https://github.com/ethereum/execution-spec-tests/pulls) are welcome!
+
+!!! bug "Reporting a Vulnerability"
+
+ Care is required when adding PRs or issues for functionality that is live on Ethereum mainnet. Please report vulnerabilities and verify bounty eligibility via the [bug bounty program](https://bounty.ethereum.org).
+
+ - **Please do not create a PR with a vulnerability visible.**
+ - **Please do not file a public ticket mentioning the vulnerability.**
diff --git a/docs/navigation.md b/docs/navigation.md
index 6063243b3c..7d8d057859 100644
--- a/docs/navigation.md
+++ b/docs/navigation.md
@@ -1,6 +1,6 @@
+ * [Home](index.md)
* Getting Started
- * [Overview](getting_started/overview.md)
* [Installation](getting_started/installation.md)
* [Installation Troubleshooting](getting_started/installation_troubleshooting.md)
* [VS Code Setup](getting_started/setup_vs_code.md)