@logickernel/agileflow 0.17.0 → 0.17.1
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +54 -127
- package/docs/guides/github-actions.md +110 -0
- package/docs/guides/gitlab-ci.md +128 -0
- package/docs/guides/other-ci.md +93 -0
- package/docs/index.md +58 -0
- package/docs/reference/cli.md +124 -0
- package/docs/reference/conventional-commits.md +133 -0
- package/docs/start-here/getting-started.md +83 -0
- package/package.json +1 -1
- package/src/git-push.js +2 -4
- package/src/github-push.js +2 -4
- package/src/gitlab-push.js +3 -5
- package/src/index.js +18 -42
- package/docs/README.md +0 -60
- package/docs/best-practices.md +0 -306
- package/docs/branching-strategy.md +0 -347
- package/docs/cli-reference.md +0 -301
- package/docs/configuration.md +0 -217
- package/docs/conventional-commits.md +0 -252
- package/docs/getting-started.md +0 -231
- package/docs/installation.md +0 -300
- package/docs/migration-guide.md +0 -303
- package/docs/release-management.md +0 -309
- package/docs/troubleshooting.md +0 -367
- package/docs/version-centric-cicd.md +0 -289
package/README.md
CHANGED
|
@@ -2,63 +2,59 @@
|
|
|
2
2
|
|
|
3
3
|
# AgileFlow
|
|
4
4
|
|
|
5
|
-
|
|
6
|
-
|
|
7
|
-
AgileFlow enforces Semantic Versioning and integrates seamlessly with your CI/CD pipeline to ensure a structured, efficient, and predictable development lifecycle. **All versions are calculated from the main branch's commit history** using [Conventional Commits](https://www.conventionalcommits.org/), ensuring consistent versioning and release notes. Whether for small projects or large-scale deployments, AgileFlow simplifies versioning and release management.
|
|
5
|
+
AgileFlow reads your commit history and automatically creates a semantic version tag on every merge to main. Your build and deploy pipelines then trigger on the tag — keeping versioning completely separate from everything else.
|
|
8
6
|
|
|
9
7
|

|
|
10
8
|
|
|
11
|
-
|
|
9
|
+
No config files. No servers. Versions are calculated from your [Conventional Commits](https://www.conventionalcommits.org/) and pushed as annotated git tags.
|
|
12
10
|
|
|
13
11
|
---
|
|
14
12
|
|
|
15
13
|
## Quick Start
|
|
16
14
|
|
|
17
|
-
|
|
15
|
+
Preview your next version in any git repository:
|
|
18
16
|
|
|
19
17
|
```bash
|
|
20
|
-
|
|
18
|
+
npx @logickernel/agileflow
|
|
21
19
|
```
|
|
22
20
|
|
|
23
|
-
### Preview Your Next Version
|
|
24
|
-
|
|
25
|
-
```bash
|
|
26
|
-
agileflow
|
|
27
21
|
```
|
|
22
|
+
Commits since current version (3):
|
|
23
|
+
a1b2c3d feat: add dark mode
|
|
24
|
+
d4e5f6a fix: resolve login timeout
|
|
25
|
+
7g8h9i0 docs: update README
|
|
28
26
|
|
|
29
|
-
|
|
27
|
+
Current version: v1.4.2
|
|
28
|
+
New version: v1.5.0
|
|
30
29
|
|
|
30
|
+
Changelog:
|
|
31
31
|
|
|
32
|
-
|
|
33
|
-
|
|
34
|
-
agileflow push
|
|
35
|
-
```
|
|
36
|
-
|
|
37
|
-
#### CD/CI
|
|
32
|
+
### Features
|
|
33
|
+
- add dark mode
|
|
38
34
|
|
|
39
|
-
|
|
40
|
-
|
|
41
|
-
agileflow github
|
|
35
|
+
### Bug fixes
|
|
36
|
+
- resolve login timeout
|
|
42
37
|
```
|
|
43
38
|
|
|
44
|
-
|
|
45
|
-
```bash
|
|
46
|
-
agileflow gitlab
|
|
47
|
-
```
|
|
48
|
-
|
|
49
|
-
**Learn More**: [Getting Started Guide](./docs/getting-started.md) • [CLI Reference](./docs/cli-reference.md)
|
|
39
|
+
This is read-only — it never creates tags or modifies anything.
|
|
50
40
|
|
|
51
41
|
---
|
|
52
42
|
|
|
53
43
|
## CI/CD Integration
|
|
54
44
|
|
|
55
|
-
AgileFlow uses a **two-step
|
|
45
|
+
AgileFlow uses a **decoupled two-step approach**:
|
|
56
46
|
|
|
57
|
-
|
|
47
|
+
1. **Versioning** — AgileFlow runs on merge to main and creates a version tag
|
|
48
|
+
2. **Release** — Your existing build and deploy pipelines trigger on the tag
|
|
49
|
+
|
|
50
|
+
```
|
|
51
|
+
Merge to main → AgileFlow → Tag v1.5.0 → Your build/deploy
|
|
52
|
+
```
|
|
58
53
|
|
|
59
|
-
|
|
54
|
+
### GitHub Actions
|
|
55
|
+
|
|
56
|
+
`.github/workflows/version.yml`:
|
|
60
57
|
|
|
61
|
-
**GitHub Actions** (`.github/workflows/version.yml`):
|
|
62
58
|
```yaml
|
|
63
59
|
name: Version
|
|
64
60
|
on:
|
|
@@ -83,16 +79,11 @@ jobs:
|
|
|
83
79
|
run: npx @logickernel/agileflow github
|
|
84
80
|
```
|
|
85
81
|
|
|
86
|
-
|
|
87
|
-
|
|
88
|
-
For a job tagged with `agileflow` for a GitLab Runner:
|
|
82
|
+
Requires an `AGILEFLOW_TOKEN` secret — a Personal Access Token with `Contents: Read and write` permission.
|
|
89
83
|
|
|
90
|
-
|
|
91
|
-
include:
|
|
92
|
-
- remote: https://code.logickernel.com/tools/agileflow/-/raw/main/.gitlab-ci.yml
|
|
93
|
-
```
|
|
84
|
+
### GitLab CI
|
|
94
85
|
|
|
95
|
-
|
|
86
|
+
`.gitlab-ci.yml`:
|
|
96
87
|
|
|
97
88
|
```yaml
|
|
98
89
|
agileflow:
|
|
@@ -104,114 +95,50 @@ agileflow:
|
|
|
104
95
|
- if: '$CI_COMMIT_BRANCH == "main"'
|
|
105
96
|
```
|
|
106
97
|
|
|
107
|
-
|
|
108
|
-
|
|
109
|
-
Configure your existing build and deploy pipelines to trigger on tag creation. When AgileFlow creates a version tag (e.g., `v1.2.3`), your CI/CD platform triggers your release workflow. Use the tag name as the version identifier for your builds and deployments.
|
|
110
|
-
|
|
111
|
-
**Learn More**: [Installation Guide](./docs/installation.md) for detailed setup instructions and examples.
|
|
112
|
-
|
|
113
|
-
### Benefits of Decoupled Architecture
|
|
114
|
-
|
|
115
|
-
- **Separation of concerns** — Versioning is independent from build/deploy
|
|
116
|
-
- **Flexibility** — Hook any process to tag creation
|
|
117
|
-
- **Reusability** — Same build pipeline works for any version
|
|
118
|
-
- **Simplicity** — Each pipeline has a single responsibility
|
|
119
|
-
|
|
120
|
-
**Learn More**: [Installation Guide](./docs/installation.md) • [Configuration](./docs/configuration.md)
|
|
121
|
-
|
|
122
|
-
---
|
|
123
|
-
|
|
124
|
-
## Conventional Commits
|
|
98
|
+
Requires an `AGILEFLOW_TOKEN` CI/CD variable — a Project Access Token with `api` scope and `Maintainer` role.
|
|
125
99
|
|
|
126
|
-
|
|
100
|
+
### Other platforms
|
|
127
101
|
|
|
128
|
-
```
|
|
129
|
-
|
|
102
|
+
```bash
|
|
103
|
+
agileflow push # creates tag and pushes to origin
|
|
104
|
+
agileflow push upstream # pushes to a different remote
|
|
130
105
|
```
|
|
131
106
|
|
|
132
|
-
The commit type (`feat`, `fix`, `perf`, etc.) indicates what kind of change was made, while the optional scope identifies the area affected. Breaking changes are marked with `!` or a `BREAKING CHANGE:` footer.
|
|
133
|
-
|
|
134
|
-
**Learn More**: [Conventional Commits Guide](./docs/conventional-commits.md)
|
|
135
|
-
|
|
136
107
|
---
|
|
137
108
|
|
|
138
|
-
##
|
|
139
|
-
|
|
140
|
-
### Automatic Versioning
|
|
109
|
+
## Conventional Commits
|
|
141
110
|
|
|
142
|
-
|
|
111
|
+
AgileFlow determines the version bump from commit types:
|
|
143
112
|
|
|
144
|
-
|
|
113
|
+
| Commit | Example | Before v1.0.0 | v1.0.0 and after |
|
|
114
|
+
|--------|---------|---------------|------------------|
|
|
115
|
+
| Breaking change | `feat!: redesign API` | minor bump | major bump |
|
|
116
|
+
| `feat` | `feat: add login` | minor bump | minor bump |
|
|
117
|
+
| `fix` | `fix: resolve crash` | patch bump | patch bump |
|
|
118
|
+
| Everything else | `docs: update README` | no bump | no bump |
|
|
145
119
|
|
|
146
|
-
|
|
120
|
+
The highest-priority bump across all commits since the last tag wins. If no bump-triggering commits exist, AgileFlow exits without creating a tag.
|
|
147
121
|
|
|
148
|
-
|
|
122
|
+
### v1.0.0 — First stable release
|
|
149
123
|
|
|
150
|
-
|
|
124
|
+
New projects start at `v0.0.0`. AgileFlow increments automatically from there. When your API is stable and ready for production, create `v1.0.0` manually:
|
|
151
125
|
|
|
152
126
|
```bash
|
|
153
127
|
git tag -a v1.0.0 -m "First stable release"
|
|
154
128
|
git push origin v1.0.0
|
|
155
129
|
```
|
|
156
130
|
|
|
157
|
-
After
|
|
158
|
-
|
|
159
|
-
|
|
160
|
-
**Learn More**: [Release Management Guide](./docs/release-management.md)
|
|
161
|
-
|
|
162
|
-
---
|
|
163
|
-
|
|
164
|
-
## Version Calculation
|
|
165
|
-
|
|
166
|
-
AgileFlow analyzes commits since the last version tag to determine the appropriate version bump:
|
|
167
|
-
|
|
168
|
-
| Commit Type | Example | Changelog | 0.x.x | 1.0.0+ |
|
|
169
|
-
|-------------|---------|-----------|-------|--------|
|
|
170
|
-
| Breaking change | `feat!: redesign API` | Add entry | **Minor** (0.1.0 → 0.2.0) | **Major** (1.0.0 → 2.0.0) |
|
|
171
|
-
| Feature | `feat: add login` | Add entry | **Minor** | **Minor** |
|
|
172
|
-
| Fix | `fix: resolve crash` | Add entry | **Patch** | **Patch** |
|
|
173
|
-
| Chore | `chore: update dependencies` | **No** entry | No bump | No bump |
|
|
174
|
-
| Everything else | `docs: update README` | Add entry | No bump | No bump |
|
|
175
|
-
|
|
176
|
-
---
|
|
177
|
-
|
|
178
|
-
## Core Principles
|
|
179
|
-
|
|
180
|
-
### Main Branch Strategy
|
|
181
|
-
|
|
182
|
-
The main branch is the single source of truth for all releases:
|
|
183
|
-
|
|
184
|
-
- **Single Version Sequence** — All versions created from the same branch
|
|
185
|
-
- **Simplified Workflow** — No release branches needed
|
|
186
|
-
- **Consistent History** — All releases share the same commit history
|
|
187
|
-
- **Easy Rollbacks** — Deploy any previous version tag
|
|
188
|
-
|
|
189
|
-
### Version-Centric Deployments
|
|
190
|
-
|
|
191
|
-
Every environment runs the same immutable version:
|
|
192
|
-
|
|
193
|
-
```
|
|
194
|
-
Tag v1.2.3 ──▶ Build ──▶ Staging
|
|
195
|
-
──▶ Production
|
|
196
|
-
──▶ Any environment
|
|
197
|
-
```
|
|
198
|
-
|
|
199
|
-
**Learn More**: [Branching Strategy](./docs/branching-strategy.md) • [Version-Centric CI/CD](./docs/version-centric-cicd.md)
|
|
131
|
+
After `v1.0.0`, breaking changes bump the major version.
|
|
200
132
|
|
|
201
133
|
---
|
|
202
134
|
|
|
203
135
|
## Documentation
|
|
204
136
|
|
|
205
|
-
|
|
|
206
|
-
|
|
207
|
-
| [Getting Started](./docs/getting-started.md) |
|
|
208
|
-
| [
|
|
209
|
-
| [
|
|
210
|
-
| [
|
|
211
|
-
| [
|
|
212
|
-
| [
|
|
213
|
-
| [Version-Centric CI/CD](./docs/version-centric-cicd.md) | Pipeline methodology |
|
|
214
|
-
| [Release Management](./docs/release-management.md) | Managing releases effectively |
|
|
215
|
-
| [Migration Guide](./docs/migration-guide.md) | Transitioning from other approaches |
|
|
216
|
-
| [Best Practices](./docs/best-practices.md) | Recommended patterns |
|
|
217
|
-
| [Troubleshooting](./docs/troubleshooting.md) | Common issues and solutions |
|
|
137
|
+
| | |
|
|
138
|
+
|-|-|
|
|
139
|
+
| [Getting Started](./docs/start-here/getting-started.md) | Run locally, understand the output, first CI setup |
|
|
140
|
+
| [GitHub Actions](./docs/guides/github-actions.md) | Token setup, workflow files, troubleshooting |
|
|
141
|
+
| [GitLab CI](./docs/guides/gitlab-ci.md) | Token setup, pipeline config, troubleshooting |
|
|
142
|
+
| [Other CI/CD](./docs/guides/other-ci.md) | Git-push integration for any platform |
|
|
143
|
+
| [CLI Reference](./docs/reference/cli.md) | All commands and options |
|
|
144
|
+
| [Conventional Commits](./docs/reference/conventional-commits.md) | Commit format and changelog behavior |
|
|
@@ -0,0 +1,110 @@
|
|
|
1
|
+
# GitHub Actions
|
|
2
|
+
|
|
3
|
+
Two workflows: one that runs AgileFlow on push to main and creates a version tag, and one that triggers on that tag to build and deploy.
|
|
4
|
+
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
## Step 1: Create an access token
|
|
8
|
+
|
|
9
|
+
1. Go to **Settings → Developer settings → Personal access tokens → Fine-grained tokens**
|
|
10
|
+
2. Click **Generate new token**
|
|
11
|
+
3. Set:
|
|
12
|
+
- **Name**: `AgileFlow`
|
|
13
|
+
- **Repository access**: your repository
|
|
14
|
+
- **Permissions**: `Contents: Read and write`
|
|
15
|
+
4. Copy the token
|
|
16
|
+
|
|
17
|
+
## Step 2: Add the token as a secret
|
|
18
|
+
|
|
19
|
+
1. In your repository: **Settings → Secrets and variables → Actions**
|
|
20
|
+
2. Click **New repository secret**
|
|
21
|
+
3. Name: `AGILEFLOW_TOKEN`, value: your token
|
|
22
|
+
|
|
23
|
+
## Step 3: Create the versioning workflow
|
|
24
|
+
|
|
25
|
+
`.github/workflows/version.yml`:
|
|
26
|
+
|
|
27
|
+
```yaml
|
|
28
|
+
name: Version
|
|
29
|
+
on:
|
|
30
|
+
push:
|
|
31
|
+
branches: [main]
|
|
32
|
+
|
|
33
|
+
jobs:
|
|
34
|
+
version:
|
|
35
|
+
runs-on: ubuntu-latest
|
|
36
|
+
steps:
|
|
37
|
+
- uses: actions/checkout@v4
|
|
38
|
+
with:
|
|
39
|
+
fetch-depth: 0
|
|
40
|
+
|
|
41
|
+
- uses: actions/setup-node@v4
|
|
42
|
+
with:
|
|
43
|
+
node-version: '20'
|
|
44
|
+
|
|
45
|
+
- name: Create version tag
|
|
46
|
+
env:
|
|
47
|
+
AGILEFLOW_TOKEN: ${{ secrets.AGILEFLOW_TOKEN }}
|
|
48
|
+
run: npx @logickernel/agileflow github
|
|
49
|
+
```
|
|
50
|
+
|
|
51
|
+
`fetch-depth: 0` is required — without it, AgileFlow can only see a shallow clone and cannot find the last version tag.
|
|
52
|
+
|
|
53
|
+
## Step 4: Create the release workflow
|
|
54
|
+
|
|
55
|
+
`.github/workflows/release.yml`:
|
|
56
|
+
|
|
57
|
+
```yaml
|
|
58
|
+
name: Release
|
|
59
|
+
on:
|
|
60
|
+
push:
|
|
61
|
+
tags:
|
|
62
|
+
- 'v*'
|
|
63
|
+
|
|
64
|
+
jobs:
|
|
65
|
+
build:
|
|
66
|
+
runs-on: ubuntu-latest
|
|
67
|
+
steps:
|
|
68
|
+
- uses: actions/checkout@v4
|
|
69
|
+
|
|
70
|
+
- name: Get version
|
|
71
|
+
run: echo "VERSION=${GITHUB_REF#refs/tags/}" >> $GITHUB_ENV
|
|
72
|
+
|
|
73
|
+
- name: Build
|
|
74
|
+
run: |
|
|
75
|
+
docker build -t myapp:$VERSION .
|
|
76
|
+
docker push myapp:$VERSION
|
|
77
|
+
|
|
78
|
+
deploy:
|
|
79
|
+
needs: build
|
|
80
|
+
runs-on: ubuntu-latest
|
|
81
|
+
environment: production
|
|
82
|
+
steps:
|
|
83
|
+
- name: Deploy
|
|
84
|
+
run: kubectl set image deployment/myapp myapp=myapp:$VERSION
|
|
85
|
+
```
|
|
86
|
+
|
|
87
|
+
---
|
|
88
|
+
|
|
89
|
+
## How it works end to end
|
|
90
|
+
|
|
91
|
+
1. You push a `feat:` commit to main
|
|
92
|
+
2. The `version` workflow runs AgileFlow, which creates tag `v1.5.0` via the GitHub API
|
|
93
|
+
3. The tag push triggers the `release` workflow
|
|
94
|
+
4. Your build runs with `VERSION=v1.5.0`
|
|
95
|
+
|
|
96
|
+
If no bump is needed (all commits are `chore`, `docs`, etc.), AgileFlow exits without creating a tag, and the release workflow never runs.
|
|
97
|
+
|
|
98
|
+
---
|
|
99
|
+
|
|
100
|
+
## Troubleshooting
|
|
101
|
+
|
|
102
|
+
**"AGILEFLOW_TOKEN not set"** — The secret is missing or not passed via `env:`. Verify the secret exists and the `env:` block is present in the step.
|
|
103
|
+
|
|
104
|
+
**"Resource not accessible by integration" / 403** — The token lacks `Contents: Read and write` permission. Regenerate with the correct scope.
|
|
105
|
+
|
|
106
|
+
**"Bad credentials" / 401** — The token has expired or was revoked. Regenerate and update the secret.
|
|
107
|
+
|
|
108
|
+
**Tag created but release workflow didn't run** — Check that the release workflow trigger is `push: tags: ['v*']`, not `push: branches: [main]`.
|
|
109
|
+
|
|
110
|
+
**"Current version: none"** — `fetch-depth: 0` is missing from the checkout step. AgileFlow cannot see the tag history in a shallow clone.
|
|
@@ -0,0 +1,128 @@
|
|
|
1
|
+
# GitLab CI
|
|
2
|
+
|
|
3
|
+
One pipeline job creates the version tag on push to main. A separate pipeline (triggered by the tag) builds and deploys.
|
|
4
|
+
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
## Step 1: Create an access token
|
|
8
|
+
|
|
9
|
+
**Recommended: Project Access Token**
|
|
10
|
+
|
|
11
|
+
1. Go to project **Settings → Access tokens**
|
|
12
|
+
2. Create:
|
|
13
|
+
- **Name**: `AgileFlow`
|
|
14
|
+
- **Role**: `Maintainer`
|
|
15
|
+
- **Scopes**: `api`
|
|
16
|
+
3. Copy the token
|
|
17
|
+
|
|
18
|
+
**Alternative: Personal Access Token**
|
|
19
|
+
|
|
20
|
+
1. Go to user **Settings → Access tokens**
|
|
21
|
+
2. Create with `api` scope
|
|
22
|
+
3. Copy the token
|
|
23
|
+
|
|
24
|
+
## Step 2: Add the token as a CI/CD variable
|
|
25
|
+
|
|
26
|
+
1. Go to project **Settings → CI/CD → Variables**
|
|
27
|
+
2. Add:
|
|
28
|
+
- **Key**: `AGILEFLOW_TOKEN`
|
|
29
|
+
- **Value**: your token
|
|
30
|
+
- **Flags**: Protected, Masked
|
|
31
|
+
|
|
32
|
+
## Step 3: Configure your pipeline
|
|
33
|
+
|
|
34
|
+
`.gitlab-ci.yml`:
|
|
35
|
+
|
|
36
|
+
```yaml
|
|
37
|
+
stages:
|
|
38
|
+
- version
|
|
39
|
+
- build
|
|
40
|
+
- deploy
|
|
41
|
+
|
|
42
|
+
# Runs on push to main — creates the version tag
|
|
43
|
+
agileflow:
|
|
44
|
+
stage: version
|
|
45
|
+
image: node:20
|
|
46
|
+
script:
|
|
47
|
+
- npm install -g @logickernel/agileflow
|
|
48
|
+
- agileflow version
|
|
49
|
+
- agileflow gitlab
|
|
50
|
+
rules:
|
|
51
|
+
- if: '$CI_COMMIT_BRANCH == "main"'
|
|
52
|
+
|
|
53
|
+
# Runs when a version tag is created — builds the release
|
|
54
|
+
build:
|
|
55
|
+
stage: build
|
|
56
|
+
script:
|
|
57
|
+
- docker build -t myapp:$CI_COMMIT_TAG .
|
|
58
|
+
- docker push myapp:$CI_COMMIT_TAG
|
|
59
|
+
rules:
|
|
60
|
+
- if: '$CI_COMMIT_TAG =~ /^v/'
|
|
61
|
+
|
|
62
|
+
# Runs when a version tag is created — deploys to staging automatically
|
|
63
|
+
deploy-staging:
|
|
64
|
+
stage: deploy
|
|
65
|
+
script:
|
|
66
|
+
- kubectl set image deployment/myapp myapp=myapp:$CI_COMMIT_TAG
|
|
67
|
+
environment:
|
|
68
|
+
name: staging
|
|
69
|
+
rules:
|
|
70
|
+
- if: '$CI_COMMIT_TAG =~ /^v/'
|
|
71
|
+
|
|
72
|
+
# Runs when a version tag is created — deploys to production manually
|
|
73
|
+
deploy-production:
|
|
74
|
+
stage: deploy
|
|
75
|
+
script:
|
|
76
|
+
- kubectl set image deployment/myapp myapp=myapp:$CI_COMMIT_TAG
|
|
77
|
+
environment:
|
|
78
|
+
name: production
|
|
79
|
+
when: manual
|
|
80
|
+
rules:
|
|
81
|
+
- if: '$CI_COMMIT_TAG =~ /^v/'
|
|
82
|
+
```
|
|
83
|
+
|
|
84
|
+
The `agileflow version` line before `agileflow gitlab` is optional but useful for confirming which version of the tool is running when troubleshooting.
|
|
85
|
+
|
|
86
|
+
---
|
|
87
|
+
|
|
88
|
+
## How it works end to end
|
|
89
|
+
|
|
90
|
+
1. You push a `feat:` commit to main
|
|
91
|
+
2. The `agileflow` job runs and creates tag `v1.5.0` via the GitLab API
|
|
92
|
+
3. GitLab starts a new pipeline for the tag
|
|
93
|
+
4. `build` and `deploy-*` jobs run with `CI_COMMIT_TAG=v1.5.0`
|
|
94
|
+
|
|
95
|
+
If no bump is needed (all commits are `chore`, `docs`, etc.), AgileFlow exits without creating a tag, and no release pipeline runs.
|
|
96
|
+
|
|
97
|
+
---
|
|
98
|
+
|
|
99
|
+
## Shallow clone behavior
|
|
100
|
+
|
|
101
|
+
GitLab CI uses shallow clones by default (`GIT_DEPTH: 20`). AgileFlow handles this by reading tag metadata directly from the remote via `git ls-remote` instead of relying on a full fetch. This works without any extra configuration in most cases.
|
|
102
|
+
|
|
103
|
+
If you see `Current version: none` despite having version tags, set a larger depth or disable shallow cloning:
|
|
104
|
+
|
|
105
|
+
```yaml
|
|
106
|
+
variables:
|
|
107
|
+
GIT_DEPTH: 0 # fetch full history
|
|
108
|
+
```
|
|
109
|
+
|
|
110
|
+
---
|
|
111
|
+
|
|
112
|
+
## Troubleshooting
|
|
113
|
+
|
|
114
|
+
**"AGILEFLOW_TOKEN not set"** — The CI/CD variable is missing. Verify it exists under **Settings → CI/CD → Variables**.
|
|
115
|
+
|
|
116
|
+
**"403 Forbidden"** — The token lacks `api` scope or `Maintainer` role. Regenerate with the correct permissions.
|
|
117
|
+
|
|
118
|
+
**"401 Unauthorized"** — The token has expired. Regenerate and update the variable.
|
|
119
|
+
|
|
120
|
+
**Tag created but no build pipeline** — Check that build/deploy rules use `$CI_COMMIT_TAG =~ /^v/`, not `$CI_COMMIT_BRANCH`.
|
|
121
|
+
|
|
122
|
+
**`Current version: none` on first run** — Expected if you have no version tags yet. AgileFlow will start from `v0.0.0`. Create a manual tag first if you need a specific starting point:
|
|
123
|
+
```bash
|
|
124
|
+
git tag -a v1.0.0 -m "First stable release"
|
|
125
|
+
git push origin v1.0.0
|
|
126
|
+
```
|
|
127
|
+
|
|
128
|
+
**Both main and tag pipelines run at the same time** — This is normal. The main pipeline creates the tag; the tag triggers the release pipeline. They are independent.
|
|
@@ -0,0 +1,93 @@
|
|
|
1
|
+
# Other CI/CD Platforms
|
|
2
|
+
|
|
3
|
+
For platforms without a native AgileFlow integration, use the `push` command. It creates an annotated git tag and pushes it to a git remote using standard git commands and your existing credentials.
|
|
4
|
+
|
|
5
|
+
```bash
|
|
6
|
+
agileflow push # push to origin (default)
|
|
7
|
+
agileflow push upstream # push to a different remote
|
|
8
|
+
```
|
|
9
|
+
|
|
10
|
+
---
|
|
11
|
+
|
|
12
|
+
## Basic setup
|
|
13
|
+
|
|
14
|
+
Configure git identity and credentials in your CI environment, then run:
|
|
15
|
+
|
|
16
|
+
```bash
|
|
17
|
+
git config user.name "CI Bot"
|
|
18
|
+
git config user.email "ci@example.com"
|
|
19
|
+
npx @logickernel/agileflow push
|
|
20
|
+
```
|
|
21
|
+
|
|
22
|
+
Then configure your CI platform to trigger build/deploy pipelines on tag creation.
|
|
23
|
+
|
|
24
|
+
---
|
|
25
|
+
|
|
26
|
+
## Examples
|
|
27
|
+
|
|
28
|
+
### Jenkins
|
|
29
|
+
|
|
30
|
+
```groovy
|
|
31
|
+
pipeline {
|
|
32
|
+
agent any
|
|
33
|
+
stages {
|
|
34
|
+
stage('Version') {
|
|
35
|
+
when { branch 'main' }
|
|
36
|
+
steps {
|
|
37
|
+
sh '''
|
|
38
|
+
git config user.name "Jenkins"
|
|
39
|
+
git config user.email "jenkins@example.com"
|
|
40
|
+
npx @logickernel/agileflow push
|
|
41
|
+
'''
|
|
42
|
+
}
|
|
43
|
+
}
|
|
44
|
+
}
|
|
45
|
+
}
|
|
46
|
+
```
|
|
47
|
+
|
|
48
|
+
### Bitbucket Pipelines
|
|
49
|
+
|
|
50
|
+
```yaml
|
|
51
|
+
pipelines:
|
|
52
|
+
branches:
|
|
53
|
+
main:
|
|
54
|
+
- step:
|
|
55
|
+
name: Version
|
|
56
|
+
script:
|
|
57
|
+
- git config user.name "Bitbucket Pipelines"
|
|
58
|
+
- git config user.email "ci@example.com"
|
|
59
|
+
- npx @logickernel/agileflow push
|
|
60
|
+
```
|
|
61
|
+
|
|
62
|
+
### CircleCI
|
|
63
|
+
|
|
64
|
+
```yaml
|
|
65
|
+
jobs:
|
|
66
|
+
version:
|
|
67
|
+
docker:
|
|
68
|
+
- image: cimg/node:20.0
|
|
69
|
+
steps:
|
|
70
|
+
- checkout
|
|
71
|
+
- run:
|
|
72
|
+
name: Create version tag
|
|
73
|
+
command: |
|
|
74
|
+
git config user.name "CircleCI"
|
|
75
|
+
git config user.email "ci@example.com"
|
|
76
|
+
npx @logickernel/agileflow push
|
|
77
|
+
|
|
78
|
+
workflows:
|
|
79
|
+
main:
|
|
80
|
+
jobs:
|
|
81
|
+
- version:
|
|
82
|
+
filters:
|
|
83
|
+
branches:
|
|
84
|
+
only: main
|
|
85
|
+
```
|
|
86
|
+
|
|
87
|
+
---
|
|
88
|
+
|
|
89
|
+
## Requirements
|
|
90
|
+
|
|
91
|
+
- Git credentials must be configured for push access to the remote
|
|
92
|
+
- The CI runner must have network access to the git remote
|
|
93
|
+
- Your platform must support triggering pipelines on tag events
|
package/docs/index.md
ADDED
|
@@ -0,0 +1,58 @@
|
|
|
1
|
+
# AgileFlow
|
|
2
|
+
|
|
3
|
+
AgileFlow reads your commit history, calculates the next semantic version, and creates a git tag — automatically, on every push to main.
|
|
4
|
+
|
|
5
|
+
No config files. No servers. Just commits and tags.
|
|
6
|
+
|
|
7
|
+
```bash
|
|
8
|
+
npx @logickernel/agileflow
|
|
9
|
+
```
|
|
10
|
+
|
|
11
|
+
```
|
|
12
|
+
Commits since current version (3):
|
|
13
|
+
a1b2c3d feat: add dark mode
|
|
14
|
+
d4e5f6a fix: resolve login timeout
|
|
15
|
+
7g8h9i0 docs: update README
|
|
16
|
+
|
|
17
|
+
Current version: v1.4.2
|
|
18
|
+
New version: v1.5.0
|
|
19
|
+
|
|
20
|
+
Changelog:
|
|
21
|
+
|
|
22
|
+
### Features
|
|
23
|
+
- add dark mode
|
|
24
|
+
|
|
25
|
+
### Bug fixes
|
|
26
|
+
- resolve login timeout
|
|
27
|
+
```
|
|
28
|
+
|
|
29
|
+
---
|
|
30
|
+
|
|
31
|
+
## How it works
|
|
32
|
+
|
|
33
|
+
1. On push to main, AgileFlow analyzes commits since the last version tag
|
|
34
|
+
2. It calculates the next version using [Conventional Commits](./reference/conventional-commits.md)
|
|
35
|
+
3. It creates an annotated git tag with the changelog as the tag message
|
|
36
|
+
4. Your build and deploy pipelines trigger on the tag
|
|
37
|
+
|
|
38
|
+
This is the **decoupled architecture**: versioning is a separate concern from building and deploying.
|
|
39
|
+
|
|
40
|
+
```
|
|
41
|
+
Push to main → AgileFlow → Tag v1.5.0 → Your build/deploy pipelines
|
|
42
|
+
```
|
|
43
|
+
|
|
44
|
+
---
|
|
45
|
+
|
|
46
|
+
## Documentation
|
|
47
|
+
|
|
48
|
+
### Start Here
|
|
49
|
+
- [Getting Started](./start-here/getting-started.md) — Run AgileFlow locally, understand the output, set up your first CI integration
|
|
50
|
+
|
|
51
|
+
### Guides
|
|
52
|
+
- [GitHub Actions](./guides/github-actions.md) — Full setup for GitHub repositories
|
|
53
|
+
- [GitLab CI](./guides/gitlab-ci.md) — Full setup for GitLab repositories
|
|
54
|
+
- [Other CI/CD](./guides/other-ci.md) — Git-push based integration for any platform
|
|
55
|
+
|
|
56
|
+
### Reference
|
|
57
|
+
- [CLI Reference](./reference/cli.md) — All commands and options
|
|
58
|
+
- [Conventional Commits](./reference/conventional-commits.md) — Commit format and version impact
|