mirror of
https://github.com/kubernetes-sigs/kustomize.git
synced 2026-05-17 18:25:26 +00:00
109 lines
2.7 KiB
Markdown
109 lines
2.7 KiB
Markdown
# gorepomod
|
|
|
|
Helps when you have a git repository with multiple Go modules.
|
|
|
|
It handles tasks one might otherwise attempt with
|
|
|
|
```
|
|
find ./ -name "go.mod" | xargs {some hack}
|
|
```
|
|
|
|
Run it from a git repository root.
|
|
|
|
It walks the repository, reads `go.mod` files, builds
|
|
a model of Go modules and intra-repo module
|
|
dependencies, then performs some operation.
|
|
|
|
Install:
|
|
```
|
|
go get sigs.k8s.io/kustomize/cmd/gorepomod
|
|
```
|
|
|
|
## Usage
|
|
|
|
_Commands that change things (everything but `list`)
|
|
do nothing but log commands
|
|
unless you add the `--doIt` flag,
|
|
allowing the change._
|
|
|
|
#### `gorepomod list`
|
|
|
|
Lists modules and intra-repo dependencies.
|
|
|
|
Use this to get module names for use in other commands.
|
|
|
|
#### `gorepomod tidy`
|
|
|
|
Creates a change with mechanical updates
|
|
to `go.mod` and `go.sum` files.
|
|
|
|
#### `gorepomod unpin {module} [{conditionalmodule}]`
|
|
|
|
Creates a change to `go.mod` files.
|
|
|
|
For each module _m_ in the repository,
|
|
if _m_ depends on a _{module}_, then
|
|
_m_'s dependency on _{module} will be
|
|
replaced by a relative path to the in-repo
|
|
version of _{module}_.
|
|
|
|
If _conditionalModule_ is specified, then
|
|
the replacement of _{module}_ will happen
|
|
if _m_ depends on _{conditionalModule}_.
|
|
|
|
#### `gorepomod pin {module} [{version}]`
|
|
|
|
Creates a change to `go.mod` files.
|
|
|
|
The opposite of `unpin`.
|
|
|
|
The change removes replacements and pins _m_ to a
|
|
specific, previously tagged and released version of _{module}_.
|
|
|
|
The argument _{version}_ defaults to recent version of _{module}_.
|
|
|
|
_{version}_ should be in semver form, e.g. `v1.2.3`.
|
|
|
|
|
|
#### `gorepomod release {module} [patch|minor|major]`
|
|
|
|
Computes a new version for the module, tags the repo
|
|
with that version, and pushes the tag to the remote.
|
|
|
|
The value of the 2nd argument, either `patch` (the default),
|
|
`minor` or `major`, determines the new version.
|
|
|
|
If the existing version is _v1.2.7_, then the new version will be:
|
|
- `patch` -> _v1.2.8_
|
|
- `minor` -> _v1.3.0_
|
|
- `major` -> _v2.0.0_
|
|
|
|
After establishing the version, the command looks for a branch named
|
|
|
|
> _release-{module}/-v{major}.{minor}_
|
|
|
|
If the branch doesn't exist, the command creates it and pushes it to the remote.
|
|
|
|
The command then creates a new tag in the form
|
|
|
|
> _{module}/v{major}.{minor}.{patch}_
|
|
|
|
The command pushes this tag to the remote. This typically triggers
|
|
cloud activity to create release artifacts.
|
|
|
|
#### `gorepomod unrelease {module}`
|
|
|
|
This undoes the work of `release`, by deleting the
|
|
most recent tag both locally and at the remote.
|
|
|
|
You can then fix whatever, and re-release.
|
|
|
|
This, however, must be done almost immediately.
|
|
|
|
If there's a chance someone (or some cloud robot) already
|
|
imported the module at the given tag, then don't do this,
|
|
because it will confuse module caches.
|
|
|
|
Do a new patch release instead.
|
|
|