You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
feat: multi chain configuration using mustache templates (#228)
This pull request introduces multi-network support for the FWSS
subgraph, enabling deployment to both mainnet and Calibration testnet
with automated configuration and contract address management. The
changes refactor the build and deployment workflow to use mustache
templating for network-specific settings, add scripts for generating
configuration and constants, and update documentation to guide users
through the new process. Manual editing of contract addresses is
replaced by automated generation from a central config file.
**Copilot**
This guide details the steps required to deploy the provided subgraph to Goldsky and run the accompanying subgraph client application.
3
+
This guide details the steps required to deploy the subgraph to multiple Filecoin networks (testnet and mainnet) using mustache templating for network-specific configurations.
4
4
5
5
## Prerequisites
6
6
@@ -17,7 +17,108 @@ Before you begin, ensure you have the following installed and set up:
17
17
3. **Goldsky Account:** You need an account on Goldsky to host your subgraph. Sign up at [goldsky.com](https://goldsky.com/).
18
18
4. **Goldsky CLI:** This tool allows you to deploy subgraphs to the Goldsky platform. Follow the installation instructions in the [Goldsky Documentation](https://docs.goldsky.com/introduction).
19
19
20
-
## Deploying the Subgraph to Goldsky
20
+
## Multi-Network Configuration
21
+
22
+
This subgraph supports deployment to multiple Filecoin networks using mustache templating. The configuration is managed through:
23
+
24
+
- **`config/network.json`**: Contains network-specific contract addresses and start blocks
25
+
- **`templates/subgraph.template.yaml`**: Template file with mustache variables for subgraph configuration
26
+
- **`templates/constants.template.ts`**: Template file with mustache variables for TypeScript constants
27
+
- **`scripts/generate-config.js`**: Script to extract network-specific configuration
28
+
- **`scripts/generate-constants.js`**: Script to generate TypeScript constants from template
29
+
30
+
### Available Networks
31
+
32
+
- **Calibration**: Calibration network configuration (ready to use)
The following npm scripts are available for multi-network deployment:
60
+
61
+
**Network-specific builds:**
62
+
63
+
- `npm run build:calibration` - Build for calibration network
64
+
- `npm run build:mainnet` - Build for mainnet
65
+
66
+
**Template generation:**
67
+
68
+
- `npm run generate:yaml:calibration` - Generate subgraph.yaml for calibration
69
+
- `npm run generate:yaml:mainnet` - Generate subgraph.yaml for mainnet
70
+
71
+
**Constants generation:**
72
+
73
+
- `npm run generate:constants:calibration` - Generate contract addresses for calibration
74
+
- `npm run generate:constants:mainnet` - Generate contract addresses for mainnet
75
+
76
+
**Environment variable approach:**
77
+
78
+
```bash
79
+
# Set network via environment variable (defaults to calibration)
80
+
NETWORK=mainnet npm run precodegen
81
+
```
82
+
83
+
**Cross-Platform Compatibility**: All scripts are designed to work on Windows, macOS, and Linux without requiring shell-specific features like pipes or redirects.
84
+
85
+
## Automated Contract Address Generation
86
+
87
+
One of the key features of this setup is **automated contract address generation**. Instead of manually updating hardcoded addresses in your TypeScript files, the system automatically generates them from your network configuration.
88
+
89
+
### How It Works
90
+
91
+
1. **Configuration Source**: Contract addresses are defined in`config/network.json`
Follow these steps to build and deploy the subgraph:
23
124
@@ -35,6 +136,8 @@ Follow these steps to build and deploy the subgraph:
35
136
npm install
36
137
# or
37
138
yarn install
139
+
# or
140
+
npm install
38
141
```
39
142
40
143
3. **Authenticate with Goldsky:**
@@ -44,21 +147,16 @@ Follow these steps to build and deploy the subgraph:
44
147
goldsky login
45
148
```
46
149
47
-
4. **Generate Code:**
48
-
The Graph CLI uses the `subgraph.yaml` manifest and GraphQL schema (`schema.graphql`) to generate AssemblyScript types.
49
-
50
-
```bash
51
-
graph codegen
52
-
```
53
-
54
-
5. **Build the Subgraph:**
55
-
Compile your subgraph code into WebAssembly (WASM).
150
+
4. **Build the Subgraph:**
151
+
Compile your subgraph code into WebAssembly (WASM) for the selected network ( calibration or mainnet).
56
152
57
153
```bash
58
-
graph build
154
+
npm run build:calibration
155
+
# or
156
+
npm run build:mainnet
59
157
```
60
158
61
-
6. **Deploy to Goldsky:**
159
+
5. **Deploy to Goldsky:**
62
160
Use the Goldsky CLI to deploy your built subgraph.
63
161
64
162
```bash
@@ -69,8 +167,8 @@ Follow these steps to build and deploy the subgraph:
69
167
- Replace `<version>` with a version identifier (e.g., `v0.0.1`).
70
168
- You can manage your deployments and find your subgraph details in the [Goldsky Dashboard](https://app.goldsky.com/). The deployment command will output the GraphQL endpoint URL for your subgraph upon successful completion. **Copy this URL**, as you will need it for the client.
71
169
72
-
7. **Tag the Subgraph (Optional):**
73
-
Tag the subgraph you deployed in step 6.
170
+
6. **Tag the Subgraph (Optional):**
171
+
Tag the subgraph you deployed in step 5.
74
172
75
173
```bash
76
174
goldsky subgraph tag create <your-subgraph-name>/<version> --tag <tag-name>
@@ -90,43 +188,21 @@ If you need to make changes to the subgraph's logic, schema, or configuration, f
90
188
91
189
1. **Modify Code:** Edit the relevant files:
92
190
93
-
- `schema.graphql`: To change the data structure and entities being stored.
94
-
- `subgraph.yaml`: To update contract addresses, ABIs, start blocks, or event handlers.
191
+
- `config/network.json`: To update contract addresses.
192
+
- `schemas/schema.*.graphql`: To change the data structure and entities being stored.
193
+
- `templates/subgraph.template.yaml`: To update contract addresses, ABIs, start blocks, or event handlers.
95
194
- `src/*.ts`: To alter the logic that processes blockchain events and maps them to the defined schema entities.
96
195
- `src/utils/*.ts`: If modifying shared utility functions or constants.
97
196
98
-
2. **Important Note on PDPVerifier Address:** Several handlers make a contract call to the PDPVerifier and ServiceProviderRegistry contract. The address for these contracts is currently hardcoded in `subgraph/src/utils/constants.ts`:
**If you update the `PDPVerifier` and `ServiceProviderRegistry` contract address in your `subgraph.yaml` file to index a different deployment, you MUST also update the `ContractAddresses.PDPVerifier` and `ContractAddresses.ServiceProviderRegistry` constants in `subgraph/src/utils/constants.ts` to match the new addresses.** Failure to do so will result in the wrong contract instance being called.
116
-
117
-
3. **Regenerate Code:** After modifying the schema or manifest, always regenerate the AssemblyScript types:
118
-
119
-
```bash
120
-
graph codegen
121
-
```
122
-
123
-
4. **Rebuild:** Compile the updated subgraph code:
197
+
2. **Rebuild:** Compile the updated subgraph code using `npm run build:<network>`:
124
198
125
199
```bash
126
-
graph build
200
+
npm run build:calibration
201
+
# or
202
+
npm run build:mainnet
127
203
```
128
204
129
-
5. **Redeploy:** Deploy the new version to Goldsky. It's good practice to increment the version number:
205
+
3. **Redeploy:** Deploy the new version to Goldsky. It's good practice to increment the version number:
0 commit comments