@gallopsystems/agent-skills 1.28.0 → 1.29.0
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/package.json
CHANGED
|
@@ -22,7 +22,7 @@ doctl supports named auth contexts for managing multiple accounts/teams.
|
|
|
22
22
|
|
|
23
23
|
```bash
|
|
24
24
|
doctl auth list # list contexts; (current) marks the active one
|
|
25
|
-
doctl account get --context <name> # cheap probe: is this context valid, which account is it?
|
|
25
|
+
doctl account get --context <name> # cheap probe: is this context valid, which account is it, is it locked?
|
|
26
26
|
```
|
|
27
27
|
|
|
28
28
|
**Prefer the `--context` flag over switching.** Every doctl command accepts `--context <name>` (before or after the subcommand). This targets one account for one command without mutating global state — important when a session touches multiple accounts:
|
|
@@ -89,6 +89,24 @@ for i in $(seq 1 90); do
|
|
|
89
89
|
done
|
|
90
90
|
```
|
|
91
91
|
|
|
92
|
+
### Deployments failing for no visible reason: check account status first
|
|
93
|
+
|
|
94
|
+
A billing- or abuse-locked team leaves **running** resources up, but can't start **new** containers. App Platform doesn't say "locked" in any deployment error. Before digging into logs, code or the platform, run one command:
|
|
95
|
+
|
|
96
|
+
```bash
|
|
97
|
+
doctl account get --context <ctx> -o json | jq '{status, status_message}'
|
|
98
|
+
# {"status": "locked", "status_message": "Your team has been locked due to lack of payment or improper use ..."}
|
|
99
|
+
```
|
|
100
|
+
|
|
101
|
+
Symptoms of a locked team, all at once:
|
|
102
|
+
- Every deployment stalls in a step that needs a new instance, such as a `PRE_DEPLOY` job. It stalls for about 30 minutes, then fails with `An internal error occurred. Contact support if this persists.`
|
|
103
|
+
- That component has no logs at all. `--type run` fails with `websocket: close 1011`, and the deploy log says `No further logs available`. The job never connects to its database.
|
|
104
|
+
- DigitalOcean's automated rollback to a previously good commit hangs the same way. That rules out a code regression.
|
|
105
|
+
- Mutations fail even for people who normally have access. `create-deployment` and `apps update` return 403 `forbidden`; the dashboard shows `You don't have permission` or `Something went wrong`.
|
|
106
|
+
- The live app keeps serving, and the status page is all green.
|
|
107
|
+
|
|
108
|
+
A locked team can only be fixed by its billing owner, who pays and opens a support ticket to unlock. Balance and invoice commands (`doctl balance get`, `doctl invoice list`) return 403 for non-billing members, so `account get` may be the only signal you can see. Failed deployments aren't retried after the unlock, so push or redeploy once the team is active again.
|
|
109
|
+
|
|
92
110
|
## Logs
|
|
93
111
|
|
|
94
112
|
```bash
|
|
@@ -77,7 +77,7 @@ If the bottom PR merged before the stack object existed, `submit` prints `Could
|
|
|
77
77
|
|
|
78
78
|
**Merging is the user's call.** Permission classifiers block agent-initiated merges as "Merge Without Review". Hand the user the exact command to run, e.g. `! gh stack merge <n> --yes --squash`.
|
|
79
79
|
|
|
80
|
-
- **Plain `gh pr merge` doesn't work on a stacked PR.** Use `gh stack merge`.
|
|
80
|
+
- **Plain `gh pr merge` doesn't work on a stacked PR.** Use `gh stack merge`. The error it prints (`must be merged using the asynchronous merge REST API`) points at REST. Don't follow it; `gh stack merge` is the supported path.
|
|
81
81
|
- **`gh stack merge <n>`** merges everything up to and including PR `<n>`. A bare number is tried as a stack number first, then as a PR number.
|
|
82
82
|
- **Flags:** `--yes` plus `--squash`, `--merge` or `--rebase` (or `--merge-method <m>`). There is no `--method`. Without a method flag it reuses your last method.
|
|
83
83
|
- **All-or-nothing.** `merge failed: … has a merge conflict` then `Stack merges are atomic, so nothing was merged`. Rebase, push and retry.
|
|
@@ -98,6 +98,8 @@ If the bottom PR merged before the stack object existed, `submit` prints `Could
|
|
|
98
98
|
| `✗ failed to push <b>: … failed to push some refs` (no detail) | Almost always the pre-push hook failed, and gh stack swallows its output. Run `git push origin <b>` to see it, fix it (often env vars the hook's tests need, which you then export in the same shell), and resubmit. |
|
|
99
99
|
| `src refspec refs/heads/<b> does not match any` | The branch exists only on the remote. Run `git branch <b> origin/<b>`. |
|
|
100
100
|
| `unknown flag: --method` | Use `--squash` / `--merge` / `--rebase` or `--merge-method`. |
|
|
101
|
+
| `GraphQL: This pull request is part of a stack and must be merged using the asynchronous merge REST API` (from `gh pr merge`) | The PR is in a stack. Run `gh stack merge <n> --yes --squash` instead; it merges everything up to `<n>`. |
|
|
102
|
+
| `Merging stacked PRs via this endpoint is not supported. Use the asynchronous merge endpoint instead.` (HTTP 403, from `PUT /repos/<owner>/<repo>/pulls/<n>/merge`) | Same cause. Use `gh stack merge`. The raw fallback is `PUT …/pulls/<n>/merge-async` (returns `.details.uuid`; poll `GET …/merge-async/<uuid>` until `status: merged`). It also merges **every open PR below `<n>`**, each as its own commit on trunk, so wait for CI on all of them first. |
|
|
101
103
|
|
|
102
104
|
## Several agents or worktrees on one repo
|
|
103
105
|
|