regenerate-versions

Files (1)

• SKILL.md

SKILL.md (first lines)

# Generate again what the registry already holds

Never by hand. Fix `registry.yaml` first, then run
[regenerate.yaml](../../.github/workflows/regenerate.yaml) to generate the affected versions
again:

```sh
gh workflow run regenerate.yaml -f name=<package name> -f versions="<version>..."
gh workflow run regenerate.yaml -f name=<package name> -f dry_run=true
```

Naming no version does every version the registry holds, which for a package with a long
history is a large pull request. `dry_run` says which versions would change and commits
nothing. The pull request it opens replaces published files, so it is labelled
`replaces-published` and never set to auto-merge, and the checks fail it if auto-merge is
turned on. It is read and merged by a person; merging it is that reading's conclusion.

### What is waiting for a definition

A version that couldn't be generated at all -- the archive holds no file of the name
`files[].src` gives -- is not in the registry, so there is nothing of it to generate again. It
is on a pull request of its own, labelled `needs-definition`, with the versions of the same era.

Write the definition those versions need on that branch first -- a `version_overrides` entry
with its own `files` -- and then:

```sh
gh workflow run regenerate.yaml -f name=<package name> -f pending=true
```

That reads the definition the pull request carries rather than the one `main` has,
generates what the pull request holds, and commits onto the same branch. A version and the
definition that makes it true then merge together or not at all.

It says so and stops when the package has no such pull request, so it can't be confused with
the ordinary mode.

### What it does with them

Only the versions whose file actually changes are committed, so pointing it at a whole
package to find out whether anything moved comes to nothing when nothing did.

A version whose upstream release was changed after the fact is a different problem.
Regenerating it produces a different checksum for the same version, which is what a release
being rewritten looks like and what a lock file exists to catch. Decide whether to publish
the new file rather than regenerating by reflex.

`ar2 regenerate --dry-run` answers the same question locally, since it writes nothing. The run
that commits has to be the workflow, because ar2 commits through GitHub's API and what it
produces from here isn't signed --
[MAINTAINING.md](../../MAINTAINING.md#everything-that-writes-runs-in-github-actions) says the
rest of it.

From aquaproj/aqua-registry-g2, MIT.

More from aquaproj/aqua-registry-g2