Grammer fix and github action update

Author: nman98

.github/workflows/golangci.yml

@@ -15,7 +15,7 @@ jobs:
     - name: Setup Go
       uses: actions/setup-go@v4
       with:
-        go-version: '1.25.1'
+        go-version: '1.25'
 
     - name: Install golangci-lint
       run: go install github.com/golangci/golangci-lint/cmd/golangci-lint@latest

.github/workflows/gotest.yml

@@ -15,7 +15,7 @@ jobs:
         - name: Setup Go
           uses: actions/setup-go@v4
           with:
-            go-version: '1.25.1'
+            go-version: '1.25'
 
         - name: Run tests
           run: go test -short ./...

.github/workflows/integration-tests.yml

@@ -2,9 +2,9 @@ name: Integration Tests
 
 on:
   pull_request:
-    branches: [ main, develop ]
+    branches: [ main, dev ]
   push:
-    branches: [ main, develop ]
+    branches: [ main, dev ]
   workflow_dispatch:
     inputs:
       test_size:
@@ -28,11 +28,11 @@ jobs:
         image: timescale/timescaledb-ha:pg17
         env:
           POSTGRES_PASSWORD: test_password_12345678
-          POSTGRES_DB: gnoland
+          POSTGRES_DB: postgres
         ports:
           - 5432:5432
         options: >-
-          --health-cmd "pg_isready -U postgres -d gnoland"
+          --health-cmd "pg_isready -U postgres -d postgres"
           --health-interval 10s
           --health-timeout 5s
           --health-retries 5
@@ -55,7 +55,7 @@ jobs:
 
       - name: Initialize database schema
         run: |
-          go run indexer/main.go setup create-db
+          go run indexer/main.go setup create-db 
         env:
           DB_HOST: localhost
           DB_PORT: 5432

.github/workflows/release.yml

@@ -19,7 +19,7 @@ jobs:
       - name: Setup Go
         uses: actions/setup-go@v4
         with:
-          go-version: '1.25.1'
+          go-version: '1.25'
 
       - name: Get version
         id: version

CHANGELOG.md

@@ -16,11 +16,11 @@ In this release there are some fixes and improvements. The live process should w
 ### Changed
 
 - The CLI commands are now combined all together so the cmd/setup.go is removed and the users can now only download the main cli and initiate everything they needs for the indexer to work. [805513b](https://github.com/Cogwheel-Validator/spectra-gnoland-indexer/commit/805513b20fdd4f452e8d6f5ad6d56d318e78d5d9)
-- Changed the data and query operators to use mutex and store any data they process/collect directly into the type they need to return. There shouldn't be any major preformance difference but it should alocate less memory. [89e5b6d](https://github.com/Cogwheel-Validator/spectra-gnoland-indexer/commit/89e5b6d103710970cbe69c02865bb4b0727649b3)
+- Changed the data and query operators to use mutex and store any data they process/collect directly into the type they need to return. There shouldn't be any major perfromance difference but it should allocate less memory. [89e5b6d](https://github.com/Cogwheel-Validator/spectra-gnoland-indexer/commit/89e5b6d103710970cbe69c02865bb4b0727649b3)
 
 ### Fixed
 
-- When Indexer started to run in live mode without any previous data it should start tho prcess the data from frist block height. But instead it tried to query block height 0. [3517e5a](https://github.com/Cogwheel-Validator/spectra-gnoland-indexer/commit/3517e5aec32a21d70f43b0595d842841098a4c47)
+- When Indexer started to run in live mode without any previous data it should start to process the data from first block height. But instead it tried to query block height 0. [3517e5a](https://github.com/Cogwheel-Validator/spectra-gnoland-indexer/commit/3517e5aec32a21d70f43b0595d842841098a4c47)
 
 ## [0.2.1] - 2025-10-06
 

docs/requirements.md

@@ -66,7 +66,7 @@ and how much data is indexed you might need to increase the RAM size.
 
 The following software and OS requirements are required to run the indexer:
 
-- Go 1.25.1
+- go 1.25.4
 - TimescaleDB 2.18 or higher but with PostgresSQL 16 or higher
 - OS: Linux, anything based on Debian(Ubuntu, Mint, etc.) or RHEL(CentOS stream, Rocky Linux, etc.) should work, openSUSE also ok
 - Docker (optional)

integration/HISTORIC_REPORTS.MD

@@ -96,7 +96,7 @@ The database holds around 2.3 GB of data, out of which:
 
 The transaction general stores the most, I think this is due to events. Althoug this was synthetic representation of the data it still stores a lot of data. Untill I run the program with real data I will not know the real picture of how much do events pop up into the transactions and what kind of real data they store. This could be decreased with compressing the events but I would need to train the zstandard dirctionary for this to be efficient.
 
-Address tx stores the second most, but I think this was due to the bug. On avarage every transaction had at least one more doubled entry from the signers. I will need to fix it later. But out of 2.5 million entries there is at least 1 million duplicated entries. So in realaty this should be at least 40% less. I do not think there is much improvment for space here.
+Address tx stores the second most, but I think this was due to the bug. On average every transaction had at least one more doubled entry from the signers. I will need to fix it later. But out of 2.5 million entries there is at least 1 million duplicated entries. So in realaty this should be at least 40% less. I do not think there is much improvment for space here.
 
 Bank msg send stores the third most, this is expected as it stores the data from the bank msg send. But this is moslty because the chances for the generator to create this type of transaction is higher than the other types.
 

integration/README.md

@@ -19,7 +19,7 @@ Additional info, anything above 100K block height is not recommended
 to run. To clarify it can run but the
 generator that creates the synthetic data stores the data in the RAM 
 memory. Unless you have abnormally high RAM
-you are risking to run out of memory. On avarage I saw the RAM going 
+you are risking to run out of memory. On average I saw the RAM going 
 up to 4-5GB for the 100K blocks with 500 regular addresses and 50 
 validators.