Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

PersistentPreRun only allowed once #252

Closed
xh3b4sd opened this issue Mar 12, 2016 · 10 comments
Closed

PersistentPreRun only allowed once #252

xh3b4sd opened this issue Mar 12, 2016 · 10 comments
Labels
area/lib Methods and functions that exist in the cobra library and consumed by users kind/bug A bug in cobra; unintended behavior
Milestone

Comments

@xh3b4sd
Copy link

xh3b4sd commented Mar 12, 2016

Hello there. I am playing around with a command that defines a PersistentPreRun. This command has a sub command. This sub command as well wants to use PersistentPreRun. When the root command is executed its PersistentPreRun is executed as expected. When executing the sub command I expected both PersistentPreRuns to be executed, but only the sub command's PersistentPreRun is executed. I expect this as a bug. What do you guys think? Thanks for listening.

@xh3b4sd
Copy link
Author

xh3b4sd commented Mar 12, 2016

FYI I can work around this using PreRun for the sub command.

@n10v n10v added this to the 2.0.0 milestone Oct 30, 2017
@n10v n10v added area/lib Methods and functions that exist in the cobra library and consumed by users kind/bug A bug in cobra; unintended behavior labels Oct 30, 2017
@amanhigh
Copy link

Yes even i felt that PersistantPreRun chaining is missing hence code get duplicated in children in order to call previous Prerun.

I feel before leaf node execution all parent PersistentPreRun should be run in order.

@kurtpeek
Copy link

kurtpeek commented Jan 7, 2020

In my case, the parent is the rootCmd and its PersistentPreRun() doesn't actually use the cmd or args passed into it, so I was able to work around this by calling rootCmd.PersistentPreRun(cmd, args) explicitly in the child command:

	PersistentPreRun: func(cmd *cobra.Command, args []string) {
		rootCmd.PersistentPreRun(cmd, args)
		...
	},

@github-actions
Copy link

This issue is being marked as stale due to a long period of inactivity

@mateimicu
Copy link

I also have this use case, the PersistentPreRun of the rootCmd validates some input, and for a subcommand group, I validate another set of inputs.

I worked around this with

PersistentPreRunE: func(cmd *cobra.Command, args []string) error {
	root := cmd
	for ; root.HasParent(); root = root.Parent() {
	}
	err := root.PersistentPreRunE(cmd, args)
	...
}

I think changing now the implementations to run all the PersistentPreRunE would be a major breaking change ... If this topic develops I may have some time to contribute.

Maybe a flag can be introduced like TraverseChildren with the default on the current behaviors ?

mateimicu added a commit to mateimicu/kdiscover that referenced this issue May 1, 2020
Because cobra will only call the last PersistPreRunE we need to
simulate a cascading run.
spf13/cobra#252

We also switches every function to `...E` alternative
mateimicu added a commit to mateimicu/kdiscover that referenced this issue May 14, 2020
Because cobra will only call the last PersistPreRunE we need to
simulate a cascading run.
spf13/cobra#252

We also switches every function to `...E` alternative
@jharshman jharshman removed this from the 2.0.0 milestone Oct 14, 2020
poy added a commit to poy/cobra that referenced this issue Oct 14, 2020
PersistentPreRun and PersistentPostRun are chained together so that
each child PersistentPreRun is ran, and the PersistentPostRun are ran
in reverse order. For example:

Commands: root -> subcommand-a -> subcommand-b

root - PersistentPreRun
subcommand-a - PersistentPreRun
subcommand-b - PersistentPreRun
subcommand-b - Run
subcommand-b - PersistentPostRun
subcommand-a - PersistentPostRun

fixes spf13#252
poy added a commit to poy/cobra that referenced this issue Oct 14, 2020
PersistentPreRun and PersistentPostRun are chained together so that
each child PersistentPreRun is ran, and the PersistentPostRun are ran
in reverse order. For example:

Commands: root -> subcommand-a -> subcommand-b

root - PersistentPreRun
subcommand-a - PersistentPreRun
subcommand-b - PersistentPreRun
subcommand-b - Run
subcommand-b - PersistentPostRun
subcommand-a - PersistentPostRun

fixes spf13#252
poy added a commit to poy/cobra that referenced this issue Oct 14, 2020
PersistentPreRun and PersistentPostRun are chained together so that
each child PersistentPreRun is ran, and the PersistentPostRun are ran
in reverse order. For example:

Commands: root -> subcommand-a -> subcommand-b

root - PersistentPreRun
subcommand-a - PersistentPreRun
subcommand-b - PersistentPreRun
subcommand-b - Run
subcommand-b - PersistentPostRun
subcommand-a - PersistentPostRun

fixes spf13#252
poy added a commit to poy/cobra that referenced this issue Oct 14, 2020
PersistentPreRun and PersistentPostRun are chained together so that
each child PersistentPreRun is ran, and the PersistentPostRun are ran
in reverse order. For example:

Commands: root -> subcommand-a -> subcommand-b

root - PersistentPreRun
subcommand-a - PersistentPreRun
subcommand-b - PersistentPreRun
subcommand-b - Run
subcommand-b - PersistentPostRun
subcommand-a - PersistentPostRun

fixes spf13#252
poy added a commit to poy/cobra that referenced this issue Oct 14, 2020
PersistentPreRun and PersistentPostRun are chained together so that
each child PersistentPreRun is ran, and the PersistentPostRun are ran
in reverse order. For example:

Commands: root -> subcommand-a -> subcommand-b

root - PersistentPreRun
subcommand-a - PersistentPreRun
subcommand-b - PersistentPreRun
subcommand-b - Run
subcommand-b - PersistentPostRun
subcommand-a - PersistentPostRun
root - PersistentPostRun

fixes spf13#252
infalmo pushed a commit to cp-tools/cobra that referenced this issue Feb 3, 2021
PersistentPreRun and PersistentPostRun are chained together so that
each child PersistentPreRun is ran, and the PersistentPostRun are ran
in reverse order. For example:

Commands: root -> subcommand-a -> subcommand-b

root - PersistentPreRun
subcommand-a - PersistentPreRun
subcommand-b - PersistentPreRun
subcommand-b - Run
subcommand-b - PersistentPostRun
subcommand-a - PersistentPostRun
root - PersistentPostRun

fixes spf13#252
poy added a commit to poy/cobra that referenced this issue Jun 2, 2021
PersistentPreRun and PersistentPostRun are chained together so that
each child PersistentPreRun is ran, and the PersistentPostRun are ran
in reverse order. For example:

Commands: root -> subcommand-a -> subcommand-b

root - PersistentPreRun
subcommand-a - PersistentPreRun
subcommand-b - PersistentPreRun
subcommand-b - Run
subcommand-b - PersistentPostRun
subcommand-a - PersistentPostRun
root - PersistentPostRun

fixes spf13#252
poy added a commit to poy/cobra that referenced this issue Jun 2, 2021
PersistentPreRun and PersistentPostRun are chained together so that
each child PersistentPreRun is ran, and the PersistentPostRun are ran
in reverse order. For example:

Commands: root -> subcommand-a -> subcommand-b

root - PersistentPreRun
subcommand-a - PersistentPreRun
subcommand-b - PersistentPreRun
subcommand-b - Run
subcommand-b - PersistentPostRun
subcommand-a - PersistentPostRun
root - PersistentPostRun

fixes spf13#252
@johnSchnake
Copy link
Collaborator

I agree with the idea that some people may want them chained, others not. The docs are clear that

The Persistent*Run functions will be inherited by children if they do not declare their own.

So at the least its by definition not a bug at this point.

I can imagine this getting complicated if you have a series of commands root childA childB and we introduce the ability to chain them (instead of overwrite) then childB may become dependent on root.PersistentPreRun but then its behavior gets broken if someone else changes childA.

The PR that @poy put up (#1253) introduces a new field to trigger this behavior so at least it isn't a breaking change. It does still get potentially weird when different commands set different values for TraverseChildrenHooks. I'm on the fence but this one did have a number of reactions and actually has someone with a PR so it should be considered.

@amanhigh
Copy link

I can imagine this getting complicated if you have a series of commands root childA childB and we introduce the ability to chain them (instead of overwrite) then childB may become dependent on root.PersistentPreRun but then its behavior gets broken if someone else changes childA.

I have a contrary opinion that chaining would simplify things. Cobra provides an inheritance structure which flows very naturally.
On those Lines there could be functions which are common to all commands below it where chaining helps.

Eg. Lets say we had a google CLI
root - Login to Google Auth
gmail - Prerun specific to gmail inherited by all commands
youtube - Prerun specific to all youtube subcommands.

In such case not having pre-run at root level would force all sub-commands to call login and so on below.

Secondly you are right this could complicate structure in some cases but then user has option to not implement persistent pre-run at root level. But now this option doesn't exist at all for a Cobra User.
Also if login changes at root it would anyways break logic for commands below even if cobra doesn't allow persistent pre-run below as this would be called in some way or other by some pre-run for command.

@nanmu42
Copy link

nanmu42 commented Oct 18, 2022

I personally think this feature is a little surprising. I thought PersistentPreRun were chained and run in the order of root command -> subcommand -> subsubcommand.

Perhaps we should give #1253 a shot?

@bdwyertech
Copy link

bdwyertech commented Nov 7, 2022

I agree that chaining is desired, at least toggle-able ala #1253. To be quite honest, I expected this was how it behaved, and only just realized it is not. Just to give an idea, this is my root PersistentPreRun:

PersistentPreRun: func(cmd *cobra.Command, args []string) {
	telemetry.SentryInit(cmd)
	viper.BindPFlags(cmd.Flags())
}

I have a few nested subcommands and only realized this top-level PersistentPreRun wasn't firing when I realized that cmd arguments weren't passing through to Viper.

happyRip added a commit to TheThingsNetwork/lorawan-stack-migrate that referenced this issue Apr 25, 2023
Execute parent's persistent pre-run in subcommands spf13/cobra#252
happyRip added a commit to TheThingsNetwork/lorawan-stack-migrate that referenced this issue Apr 25, 2023
Execute parent's persistent pre-run in subcommands spf13/cobra#252
happyRip added a commit to TheThingsNetwork/lorawan-stack-migrate that referenced this issue Apr 25, 2023
Execute parent's persistent pre-run in subcommands spf13/cobra#252
happyRip added a commit to TheThingsNetwork/lorawan-stack-migrate that referenced this issue Apr 26, 2023
Execute parent's persistent pre-run in subcommands spf13/cobra#252
vkhoroz added a commit to vkhoroz/go-cobra that referenced this issue Oct 12, 2023
Currently, only one of the persistent pre-runs and post-runs is executed.
It is always the first one found in the parents chain, starting at this command.
Expected behavior is to execute all parents' persistent pre-runs and post-runs.

Dependent projects implemented various workarounds for this:
- manually building persistent hook chains (in every hook).
- applying some kind of monkey-patching on top of Cobra.

This change eliminates the necessity for such workarounds.

Note: when merged, commands which built hook chains manually
may call parents' persistent pre-runs and post-runs a more than once.
This is not a big deal when persistent hooks are used properly.
Otherwise, such projects need to be modified.

Based on the ticket history there is a limited number of projects which need to update:
- spf13#216
- spf13#252

Signed-off-by: Volodymyr Khoroz <[email protected]>
vkhoroz added a commit to vkhoroz/go-cobra that referenced this issue Oct 12, 2023
…rents

Currently, only one of the persistent pre-runs and post-runs is executed.
It is always the first one found in the parents chain, starting at this command.
Expected behavior is to execute all parents' persistent pre-runs and post-runs.

Dependent projects implemented various workarounds for this:
- manually building persistent hook chains (in every hook).
- applying some kind of monkey-patching on top of Cobra.

This change eliminates the necessity for such workarounds
by allowing to set a global variable EnableTraverseRunHooks.

Tickets:
- spf13#216
- spf13#252

Signed-off-by: Volodymyr Khoroz <[email protected]>
vkhoroz added a commit to vkhoroz/go-cobra that referenced this issue Oct 12, 2023
Currently, only one of the persistent pre-runs and post-runs is executed.
It is always the first one found in the parents chain, starting at this command.
Expected behavior is to execute all parents' persistent pre-runs and post-runs.

Dependent projects implemented various workarounds for this:
- manually building persistent hook chains (in every hook).
- applying some kind of monkey-patching on top of Cobra.

This change eliminates the necessity for such workarounds
by allowing to set a global variable EnableTraverseRunHooks.

Tickets:
- spf13#216
- spf13#252

Signed-off-by: Volodymyr Khoroz <[email protected]>
vkhoroz added a commit to vkhoroz/go-cobra that referenced this issue Oct 18, 2023
Currently, only one of the persistent pre-runs and post-runs is executed.
It is always the first one found in the parents chain, starting at this command.
Expected behavior is to execute all parents' persistent pre-runs and post-runs.

Dependent projects implemented various workarounds for this:
- manually building persistent hook chains (in every hook).
- applying some kind of monkey-patching on top of Cobra.

This change eliminates the necessity for such workarounds
by allowing to set a global variable EnableTraverseRunHooks.

Tickets:
- spf13#216
- spf13#252

Signed-off-by: Volodymyr Khoroz <[email protected]>
marckhouzam pushed a commit that referenced this issue Oct 22, 2023
Currently, only one of the persistent pre-runs and post-runs is executed.
It is always the first one found in the parents chain, starting at this command.
Expected behavior is to execute all parents' persistent pre-runs and post-runs.

Dependent projects implemented various workarounds for this:
- manually building persistent hook chains (in every hook).
- applying some kind of monkey-patching on top of Cobra.

This change eliminates the necessity for such workarounds
by allowing to set a global variable EnableTraverseRunHooks.

Tickets:
- #216
- #252

Signed-off-by: Volodymyr Khoroz <[email protected]>
@polothy
Copy link

polothy commented Nov 6, 2023

Fixed in #2044

@marckhouzam marckhouzam added this to the 1.8.0 milestone Nov 6, 2023
Dav-14 added a commit to formancehq/cobra that referenced this issue Mar 15, 2024
* Create unit test illustrating unknown flag bug (spf13#1854)

Created a unit test that tests the unknown flag
error message when the unknown flag is located
in different arg positions.

* Update stale.yml (spf13#1863)

* fix: force ForEach-Object to return array in pwsh completion (spf13#1850)

Fixes spf13#1847

* Makefile: add target richtest (spf13#1865)

Don't require contributors to install richgo but keep it as an option and for CI

* build(deps): bump golangci/golangci-lint-action from 3.2.0 to 3.3.1 (spf13#1851)

Bumps [golangci/golangci-lint-action](https://github.com/golangci/golangci-lint-action) from 3.2.0 to 3.3.1.
- [Release notes](https://github.com/golangci/golangci-lint-action/releases)
- [Commits](golangci/golangci-lint-action@v3.2.0...v3.3.1)

---
updated-dependencies:
- dependency-name: golangci/golangci-lint-action
  dependency-type: direct:production
  update-type: version-update:semver-minor
...

Signed-off-by: dependabot[bot] <[email protected]>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>

* Update kubescape org (spf13#1874)

Signed-off-by: David Wertenteil <[email protected]>

* ci: deprecate go 1.15 (spf13#1866)

Remove testing for go 1.15 to allow CI to pass, but don't force projects to upgrade.

* fix: conflict import name with variable (spf13#1879)

`template` is an import in `cobra.go` file and also used as a variable
name, which masks the library in the scope of that function.

* Update badge route (spf13#1884)

Based on
badges/shields#8671

* fix: func name in doc strings (spf13#1885)

Corrected the function name at the start of doc strings, as per the convention
outlined in official go documentation: https://go.dev/blog/godoc

* completions: do not detect arguments with dash as 2nd char as flag (spf13#1817)

Fixes spf13#1816

Previously, arguments with a dash as the second character (e.g., 1-ff00:0:1)
were detected as a flag by mistake. This resulted in auto completion misbehaving
if such an argument was last in the argument list during invocation.

* build(deps): bump github.com/inconshreveable/mousetrap (spf13#1872)

* Add documentation about disabling completion descriptions (spf13#1901)

* Improve MarkFlagsMutuallyExclusive example in User Guide (spf13#1904)

* Update shell_completions.md (spf13#1907)

align documentation with the code : completions.go:452

* build(deps): bump golangci/golangci-lint-action from 3.3.1 to 3.4.0 (spf13#1902)

* Removes stale bot from GitHub action (spf13#1908)

Signed-off-by: John McBride <[email protected]>

* Add keeporder to shell completion (spf13#1903)

This allows programs to request the shell to maintain the order of completions that was returned by the program

* Add support for PowerShell 7.2+ (spf13#1916)

PowerShell 7.2 has changed the way arguments are passed to executables.
This was originally an experimental feature in 7.2, but as of 7.3 it is
built-in. A simple "" is now sufficient for passing empty arguments, no
back-tick escaping is required.

Fixes spf13#1849

Signed-off-by: Oldřich Jedlička <[email protected]>
Co-authored-by: Oldřich Jedlička <[email protected]>

* ci: deprecate go 1.16 (spf13#1926)

* ci: test Golang 1.20 (spf13#1925)

* update copyright year (spf13#1927)

* Update projects_using_cobra.md (spf13#1932)

Signed-off-by: Florent Poinsard <[email protected]>

* Document suggested layout for subcommands (spf13#1930)

Signed-off-by: Luiz Carvalho <[email protected]>

* Allow sourcing zsh completion script (spf13#1917)

Although it is not the recommended approach, sourcing a completion
script is the simplest way to get people to try using shell completion.
Not allowing it for zsh has turned out to complicate shell completion
adoption.  Further, many tools modify the zsh script to allow sourcing.

This commit allows sourcing of the zsh completion script.

Signed-off-by: Marc Khouzam <[email protected]>

* Update main image to better handle dark background (spf13#1883)

Fixes spf13#1880

Signed-off-by: Marc Khouzam <[email protected]>
Co-authored-by: Deleplace <[email protected]>

* Fix typo in fish completions (spf13#1945)

* build(deps): bump golangci/golangci-lint-action from 3.4.0 to 3.5.0 (spf13#1971)

* Fix grammar: 'allows to' (spf13#1978)

The use in generated bash completion files is getting flagged by
Lintian (the Debian package linting tool).

Signed-off-by: Taavi Väänänen <[email protected]>

* test: make fish_completions_test more robust (spf13#1980)

Use temporary files instead of assuming the current directory is
writable. Also, if creating a temporary file still returns an error,
prevent the test from failing silently by replacing `log.Fatal` with
`t.Fatal`.

* powershell: escape variable with curly brackets (spf13#1960)

This fixes an issue with program names that include a dot, in our case
`podman.exe`. This was caused by the change in commit 6ba7ebb.

Fixes spf13#1853

Signed-off-by: Paul Holzinger <[email protected]>

* build(deps): bump golangci/golangci-lint-action from 3.5.0 to 3.6.0 (spf13#1976)

* Move documentation sources to site/content (spf13#1428)

* Add 'one required flag' group (spf13#1952)

* golangci: enable 'unused' and disable deprecated replaced by it (spf13#1983)

* doc: fix typo, Deperecated -> Deprecated (spf13#2000)

* minor corrections to unit tests (spf13#2003)

* build(deps): bump golangci/golangci-lint-action from 3.6.0 to 3.7.0 (spf13#2021)

* command: temporarily disable G602 due to securego/gosec#1005 (spf13#2022)

* ci: test golang 1.21 (spf13#2024)

* Customizable error message prefix (spf13#2023)

* feat: add getters for flag completions (spf13#1943)

* Add notes to doc on preRun and postRun condition (spf13#2041)

* build(deps): bump actions/setup-go from 3 to 4 (spf13#1934)

* build(deps): bump github.com/cpuguy83/go-md2man/v2 from 2.0.2 to 2.0.3 (spf13#2047)

* Allow running persistent run hooks of all parents (spf13#2044)

Currently, only one of the persistent pre-runs and post-runs is executed.
It is always the first one found in the parents chain, starting at this command.
Expected behavior is to execute all parents' persistent pre-runs and post-runs.

Dependent projects implemented various workarounds for this:
- manually building persistent hook chains (in every hook).
- applying some kind of monkey-patching on top of Cobra.

This change eliminates the necessity for such workarounds
by allowing to set a global variable EnableTraverseRunHooks.

Tickets:
- spf13#216
- spf13#252

Signed-off-by: Volodymyr Khoroz <[email protected]>

* Fix linter errors (spf13#2052)

When using golangci-lint v1.55.0 some new errors were being reported.

Signed-off-by: Marc Khouzam <[email protected]>

* Don't complete --help flag when flag parsing disabled (spf13#2061)

Fixes spf13#2060

When a command sets `DisableFlagParsing = true` it requests the
responsibility of doing all the flag parsing. Therefore even the
`--help/-f/--version/-v` flags should not be automatically completed
by Cobra in such a case.

Without this change the `--help/-h/--version/-v` flags can end up being
completed twice for plugins: one time from cobra and one time from the
plugin (which has set `DisableFlagParsing = true`).

Signed-off-by: Marc Khouzam <[email protected]>

* Add tests for flag completion registration (spf13#2053)

Different problems have been reported about flag completion registration.
These two tests are the cases that were not being verified but had been
mentioned as problematic.

Ref:
- spf13#1320
- spf13#1438 (comment)

Signed-off-by: Marc Khouzam <[email protected]>

* Replace all non-alphanumerics in active help env var program prefix (spf13#1940)

* Replace all non-alphanumerics in active help env var program prefix

There are other characters besides the dash that are fine in program
names, but are problematic in environment variable names. These include
(but are not limited to) period, space, and non-ASCII letters.

* Another change in docs to mention non-ASCII-alphanumeric instead of just dash

* build(deps): bump actions/checkout from 3 to 4 (spf13#2028)

* Support usage as plugin for tools like kubectl (spf13#2018)

In this case the executable is `kubectl-plugin`, but we run it as:

    kubectl plugin

And the help text should reflect the actual usage of the command.

To create a plugin, add the cobra.CommandDisplayNameAnnotation:

    rootCmd := &cobra.Command{
        Use: "plugin",
        Annotations: map[string]string{
            cobra.CommandDisplayNameAnnotation: "kubectl plugin",
        }
    }

Internally this change modifies CommandPath() for the root command to
return the command display name instead of the command name. This is
used for error messages, help text generation, and completions.

CommandPath() is expected to have spaces and code using it already
handle spaces (e.g replacing with _), so hopefully this does not break
anything.

Fixes: spf13#2017

Signed-off-by: Nir Soffer <[email protected]>

* Improve API to get flag completion function (spf13#2063)

The new API is simpler and matches the `c.RegisterFlagCompletionFunc()`
API.  By removing the global function `GetFlagCompletion()` we are more
future proof if we ever move from a global map of flag completion
functions to something associated with the command.

The commit also makes this API work with persistent flags by using
`c.Flag(flagName)` instead of `c.Flags().Lookup(flagName)`.

The commit also adds unit tests.

Signed-off-by: Marc Khouzam <[email protected]>

* feat: expose GetCompletions (was getCompletions)

---------

Signed-off-by: dependabot[bot] <[email protected]>
Signed-off-by: David Wertenteil <[email protected]>
Signed-off-by: John McBride <[email protected]>
Signed-off-by: Oldřich Jedlička <[email protected]>
Signed-off-by: Florent Poinsard <[email protected]>
Signed-off-by: Luiz Carvalho <[email protected]>
Signed-off-by: Marc Khouzam <[email protected]>
Signed-off-by: Taavi Väänänen <[email protected]>
Signed-off-by: Paul Holzinger <[email protected]>
Signed-off-by: Volodymyr Khoroz <[email protected]>
Signed-off-by: Nir Soffer <[email protected]>
Co-authored-by: Brian Pursley <[email protected]>
Co-authored-by: Enrico Candino <[email protected]>
Co-authored-by: Norman Dankert <[email protected]>
Co-authored-by: Unai Martinez-Corral <[email protected]>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Co-authored-by: David Wertenteil <[email protected]>
Co-authored-by: Yash Ladha <[email protected]>
Co-authored-by: Seonghyeon Cho <[email protected]>
Co-authored-by: Dominik Roos <[email protected]>
Co-authored-by: Shihta Kuan <[email protected]>
Co-authored-by: janhn <[email protected]>
Co-authored-by: Ggg6542 <[email protected]>
Co-authored-by: John McBride <[email protected]>
Co-authored-by: Gyanendra Mishra <[email protected]>
Co-authored-by: Oldřich Jedlička <[email protected]>
Co-authored-by: Oldřich Jedlička <[email protected]>
Co-authored-by: Florent Poinsard <[email protected]>
Co-authored-by: Luiz Carvalho <[email protected]>
Co-authored-by: Marc Khouzam <[email protected]>
Co-authored-by: Deleplace <[email protected]>
Co-authored-by: Tom Payne <[email protected]>
Co-authored-by: Taavi Väänänen <[email protected]>
Co-authored-by: Branch Vincent <[email protected]>
Co-authored-by: Paul Holzinger <[email protected]>
Co-authored-by: Martijn Evers <[email protected]>
Co-authored-by: gocurr <[email protected]>
Co-authored-by: Jun Nishimura <[email protected]>
Co-authored-by: Nuno Adrego <[email protected]>
Co-authored-by: Souma <[email protected]>
Co-authored-by: Alexandru-Claudius Virtopeanu <[email protected]>
Co-authored-by: Haoming Meng <[email protected]>
Co-authored-by: vkhoroz <[email protected]>
Co-authored-by: Ville Skyttä <[email protected]>
Co-authored-by: Nir Soffer <[email protected]>
Co-authored-by: Geoffrey Ragot <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/lib Methods and functions that exist in the cobra library and consumed by users kind/bug A bug in cobra; unintended behavior
Projects
None yet