What CodeLynq does with GitHub Actions
Two separate things, both opt-in. First, feedback: when Actions reports a failure on a pull request CodeLynq opened, or a reviewer requests changes, the run can pick that up and fix it on the same branch. The existing pull request updates — a second one is never opened for the same task.
Second, deployment. When you merge, CodeLynq can dispatch a workflow you already maintain and record the release against the commit. It does not deploy anything itself; it starts your pipeline and then tracks what your pipeline reports back.
Setting it up
- Generate a webhook secret for the repository in CodeLynq and add the webhook in GitHub with that secret.
- Enable auto-iterate on the project if you want failing checks fixed automatically.
- For deployments, add a deploy target naming the workflow file and the ref to dispatch.
- Merge a CodeLynq pull request and watch the release record appear.
Worth knowing
Every delivery is verified by signature against that repository’s own secret before anything acts on it, and an unsigned or mismatched payload is accepted and ignored rather than rejected loudly. Iterations are capped per run and count against your normal quota, so a persistently red build cannot spend your budget in a loop. Deployments only trigger for merged pull requests that came from a CodeLynq run, not for every merge in the repository.