proposal: Go 2: prohibit in-package tests from extending a package's API

Currently in-package tests are free to add exported identifiers to the package that they are testing.
Specifically an in-package test:

can define new variables
can define new types
can implement methods on non-test types

This makes tooling harder, because any given package can have several possible variants,
depending on which package's tests are being run.
Consider the following example:
-- go.mod --
module example

-- a/a.go --
package a

import (
	"fmt"

	"example/b"
)

var A fmt.Stringer = b.B{}

-- b/b.go --
package b

type B struct{}

-- b/b1_test.go --
package b

func (B) String() string { return "b" }

-- b/b2_test.go --
package b_test

import (
	"testing"

	"example/a"
)

func Test(t *testing.T) {
	if got, want := a.A.String(), "b"; got != want {
		t.Fatalf("got %q want %q", got, want)
	}
}

Running go test example/b succeeds because when b is being tested, the internal tests extended the B type so it implements fmt.Stringer. But example/a won't actually compile on its own because B doesn't implement fmt.Stringer without the test code added by the internal tests in example/b!
It's as if tests exist in a closely related but different version of the universe in which every package might not be quite the same as its usual version. And that version is potentially different for every package.
This "parallel universe" property of testing makes Go types harder to reason about and the Go tooling less efficient, because it's not possible to type-check a package once and for all in the general case.
Where does this problem come from?
Currently in Go, test code can be internal to a package, extending that package for the duration of the test and allowing the test code access to unexported identifiers within the package, or it can be external, with access to exported identifiers only. A hybrid approach is also possible, where tests are largely external, but some package-internal test code, often in an export_test.go file, is used to provide access to selected parts of the internal API.
It's the final case that is problematic, because external test code is free to depend on other packages which themselves depend on the package being tested which has been extended with extra test code.
All three approaches are common in existing Go code.
I believe that any solution to this issue should continue to support almost all existing code (including the possibility of automatic code migration with gofix), otherwise substantial parts of the ecosystem will not be able to move forward with new Go features.
Proposed solution
I propose that it should not be possible to write tests in the same package as that being tested. That is, all tests must be in the external test package (e.g. foo_test to test package foo).
A test file can use a special form of import statement to request access to unexported identifiers from the package being tested. If they use this special form, code within that file (only) may access unexported identifiers within the package without compiler errors.
A possible (straw man) spelling for the syntax is:
import "."

That is, import the package in the current directory.
This form is currently invalid because relative import paths are not allowed, and "." is not a valid package name by itself, so wouldn't overlap with existing import path syntax. As there is only one package that can be imported in this way, there is no ambiguity problem. It also satisfies issue 29036, as the imported package name can be automatically derived from the current file's package identifier by stripping the _test suffix.
Another possibility might be to add an extra keyword, recognized only within an import block; for example:
import "mypackagepath" internal

Whatever the form for the special import syntax, this solution seems to solve the initial problem. It allows both all-internal tests (always use import "."), all-external tests (never use import ".") and hybrid tests ("internal" test code can define selected functionality to be used by external tests, similarly to how export_test.go files are used today). It also reduces the overall complexity of the way that tests work in Go.
I believe that it should also be possible to automatically convert almost all existing code to the new rules. Some care would need to be taken to rename symbols that appear in both internal and external test code, but that's not an hard issue to solve. Perhaps that issue is rare enough that manual intervention could be required. More investigation is needed to see how common it is.
As an example, some test code that exposes selected functionality to external tests might look like this:
-- b/b.go --
package b

type B struct {
	internalField string
}

func GetBValue() B {
	return B{
		internalField: "b",
	}
}
-- b/b1_test.go --
package b_test
import "."		// allow access to unexported identifiers within this file.

func BInternalField(x b.B) string {
	return x.internalField
}
-- b/b2_test.go --
package b_test

import (
	"testing"

	"example/b"
)

func Test(t *testing.T) {
	x := b.GetBValue()
	if got, want := BInternalField(x), "b"; got != want {
		t.Fatalf("got %q want %q", got, want)
	}
}

Other possible solutions
We could disallow all tests that rely on direct access to unexported identifiers i.e. allow external tests only. This is an attractive option for some, but the change would be very disruptive for much code. I do not believe that it would be possible to migrate existing internal tests automatically, so I think this possibility is excluded.
We could continue to allow both internal and external tests, but treat internal test code as being in its own package, with access allowed to the tested package's unexported identifiers (and all symbols from the package available in global scope), but otherwise separate from it. External tests could use some kind of special import syntax (for example import "thispackage@test") to access symbols defined in the internal tests. This was my original thought, but the model seems more complex than necessary - we have an extra pseudo-package for tests and a special import path syntax.
We could prohibit internal test code from defining methods on types defined by the testing package. This solves some of the more obvious problems with the current situation, but the "parallel universe" issue is still present, and tooling probably would not become significantly simpler.

How are tests any different from build tags in general here? If this is a problem, shouldn't we also disallow having different APIs under different sets of build tags? How would syscall work under those assumptions? And how would you check for this (AIUI this would require solving SAT ;-) )?
i.e. I agree that you can solve the test-portion of this, but I don't think you ever can get to a point where you have any guarantees of this kind for tooling.

How are tests any different from build tags in general here?

Tests are different from build tags in general because there are no build tags for tests (deliberately).
With a given set of build tags, anything might change, but that's inevitable, given the way that build tags work. The test thing just adds another dimension to that. Even if you do know the set of build tags, you can't precompile a given package.
Consider this: with a given build environment (including tags), it is currently not possible to have a simple map from each package to type-checked information on that package.
With this proposal, that would be possible, making it easier to reason about and write tools that use that information.

I'd definitely be in favor of disallowing exported identifiers in test files.
For build tags, I wish that were possible, because it seems like a bad design to have different APIs for different platforms, but at the same time, then you have APIs that essentially lie about what they support for some platforms.
I wish there were a solution for godoc that could merge all APIs for a package and indicate which are platform-specific.

I do like the idea of keeping a package sealed off from testing code, so that the package is the package, and there's none of this kind of wacky thing where when you test, now the package has different code in it.  Adding code to the code that you're testing at test time seems like a fantastically bad idea in general.  By definition, then you're not actually testing the production code.
At the same time, I find internal tests to be immensely useful in my own work, providing fast, reliable, focused assurances that the code does what I expect it to do without having to change the API to do that testing.
Like Axel, I'm not sure about the real benefit here.   It sounds like it's intended to make tooling faster and simpler, which I am all for, but are tests really a problem?
I'd like to hear more about the problem this is solving and what the benefits are.

At the same time, I find internal tests to be immensely useful in my own work, providing fast, reliable, focused assurances that the code does what I expect it to do without having to change the API to do that testing.

This proposal still allows you to write internal tests. I'm not sure what you're driving at here.

Additions:

APIs defined in test-files can not be used by importers

There is one exception to this: foo_test can import foo and then use exported APIs created in _test.go files of foo - which is the currently recommended way to access unexported APIs from test-packages.

Adding code to the code that you're testing at test time seems like a fantastically bad idea in general. By definition, then you're not actually testing the production code.

FWIW, a case where I actually added exported methods in tests to existing types is convenience helpers for constructing nested data structures. So, for example, I have a binary tree implementation and implement fmt.Stringer and fmt.Scanner to work with ((a b) c) or the like for readability in tests. The methods have to be exported to be callable for fmt, but I don't want to commit to the format and make it part of my actual API.
Lastly: If we don't want to reduce the utility of testing (i.e. still allow accessing internal identifiers), ISTM that this would require a language change - the prohibition of accessing unexported identifiers of foreign packages is part of the language and the compiler would need to both generate the necessary symbols when compiling the package-under-test and know to allow accessing unexported identifiers in certain situations. This would also mean, that we'd have to think about how this affect third-party build tools (e.g. bazel, gb…). It definitely makes this not much of a simplification (quite the opposite). Note, that the current (tooling-only) mechanism to access unexported identifiers from a _test-package is exactly what this proposal wants to forbid.

This proposal still allows you to write tests that access internal package details. I'm not sure what you're driving at here.

I wanted to forestall any confusion in case someone might think that I wanted to remove internal testing entirely.

APIs defined in test-files can not be used by importers (as you point out, test is not a build tag). Why would you need such a map? And how is a map keyed by "import path + test(yes/no) + <build_tags>" significantly worse than a map keyed by "import path + <build_tags>" for that purpose?

Such a map can't be keyed just by (importPath, isTest, buildTags) tuple, because test isn't a bool - it's a vector. It's more like (importPath, packageUnderTest, buildTags) - i.e. each package can have an indefinite number of versions, not just two.
To demonstrate, consider the following module:
-- go.mod --
module example
-- a/a.go --
package a

import (
	"fmt"
	"reflect"

	"example/b"
	"example/c"
)

var (
	stringerType = reflect.TypeOf(new(fmt.Stringer)).Elem()
	BIsStringer  = reflect.TypeOf(b.B{}).Implements(stringerType)
	CIsStringer  = reflect.TypeOf(c.C{}).Implements(stringerType)
)
-- b/b.go --
package b

type B struct{}

-- b/b1_test.go --
package b

func (B) String() string { return "b" }

-- b/b2_test.go --
package b_test

import (
	"testing"

	"example/a"
)

func Test(t *testing.T) {
	if got, want := a.BIsStringer, true; got != want {
		t.Fatalf("B: got %v want %v", got, want)
	}
	if got, want := a.CIsStringer, false; got != want {
		t.Fatalf("C: got %v want %v", got, want)
	}
}
-- c/c.go --
package c

type C struct{}
-- c/c1_test.go --
package c

func (C) String() string { return "c" }
-- c/c2_test.go --
package c_test

import (
	"testing"

	"example/a"
)

func Test(t *testing.T) {
	if got, want := a.BIsStringer, false; got != want {
		t.Fatalf("B: got %v want %v", got, want)
	}
	if got, want := a.CIsStringer, true; got != want {
		t.Fatalf("C: got %v want %v", got, want)
	}
}

Note that Test in c2_test.go and Test in b2_test.go both expect different results.
Now let's see how this looks under the go/packages API. Here's some code to print some info about all the packages within the example module:
package main

import (
	"fmt"
	"log"
	"strings"

	"golang.org/x/tools/go/packages"
)

func main() {
	pkgs, err := packages.Load(&packages.Config{
		Mode:  packages.LoadTypes,
		Dir:   ".",
		Tests: true,
	}, "./...")
	if err != nil {
		log.Fatalf("cannot load packages: %v", err)
	}
	packages.Visit(pkgs, func(pkg *packages.Package) bool {
		if strings.HasPrefix(pkg.PkgPath, "example/") {
			fmt.Printf("%s\n", pkg.ID)
		}
		return true
	}, nil)
}

When run in the example module directory, this prints:
example/b
example/c
example/a
example/b [example/b.test]
example/b_test [example/b.test]
example/a [example/b.test]
example/b.test
example/c [example/c.test]
example/c_test [example/c.test]
example/a [example/c.test]
example/c.test

Note that there are three versions of example/a, one for each package that depends on an internal module that's under test and has internal test code. In a larger code base where we're testing a lower level package with some much higher level testing infrastructure that depends on it, the number of extra packages could be considerable.
If I was writing some vet-like tool that relied on type information, this complicates matters; for example, which versions of example/a do I report errors in? When compiling Go packages, you may have seen duplicate error message being printed. This is the reason that happens.

AFAICS if this proposal was implemented, there would be no need for any of the example/a [example/b.test]-style package identifiers - that's a complexity introduced entirely by the current system.

That's an interesting example. Effectively a circular import after all. Weird, but makes sense :)

If I was writing some vet-like tool that relied on type information, this complicates matters; for example, which versions of example/a do I report errors in?

I would argue: The one that is the root of the analysis. I.e. running go test in example/b will only encounter one version of example/b and thus only one version of example/a. It's fair though, that you can have multiple roots and that causes ambiguity.
Alright, I see how this would simplify one use case for tools :) Still am of the opinion it's not worth the downside of having to either limit testing to exported APIs or having to change the language.

Lastly: If we don't want to reduce the utility of testing (i.e. still allow accessing internal identifiers), ISTM that this would require a language change - the prohibition of accessing unexported identifiers of foreign packages is part of the language and the compiler would need to both generate the necessary symbols when compiling the package-under-test and know to allow accessing unexported identifiers in certain situations.

Yes, the compiler would need to generate unexported symbols when the package has tests that use the import "." syntax, but gc at least already generates those symbols; I don't know if gccgo elides unused unexported identifiers before link time or not.
And, yes, the compiler would need to know that unexported symbols could be accessed in this particular case, and that's is indeed a language change. Personally I think that's better than the current somewhat hacky (and problematic in the larger view of things) situation, but yours is definitely a valid perspective - there is a trade-off here.

This would also mean, that we'd have to think about how this affect third-party build tools (e.g. bazel, gb…). It definitely makes this not much of a simplification (quite the opposite).

I'm not sure. It might well end up simplifying things in those tools too. I wouldn't rush to conclusions here.

Alright, I see how this would simplify one use case for tools :)

Note that it isn't just one use case. It's the way that the whole model works.
Anyone that wants to use the go/packages tooling really should have some understanding of this. It was certainly quite surprising to me when I discovered how this works, and I suspect it would also be surprising to almost everyone else too.

@rogpeppe This proposal seems to have a few problems:

This would break every piece of testing code in the wild.
Functionally, I have never had this problem break my code, or heard of it ever being a pain point.
This is not unique to tests. For instance "syscall" type packages will have different APIs on purpose, and it is somewhat common for windows build tags to have different symbols, some perhaps exported, then other platforms.
Right now go/packages as far as I can tell, still requires a specific GOOS/GOARCH/tests/tags to process files. I view this as a problem (I won't go into details, others disagreed). I think this is a much more fundamental issue. I think this proposal is an attempt to paper over this design issue. I think a go/packages needs to expose all go files in a single query, with some helpers to get a build-able set for tools that need to resolve symbols.

Tools that work on code (API compatibility checkers, symbol rename) must be go tag (including test tag) aware.
Or you will run into further "problems" like this down the line. Yes, it will be more complicated, and will probably involve significant changes to a parser lexer to handle for many tools. But I think it would be great to handle Rename Symbol across multiple mutually exclusive build tags.

@kardianos

This would break every piece of testing code in the wild.

Could you give some concrete examples? I can't think of a single test I've ever interacted with that would break.

This is not unique to tests.

It is unique to tests in that the API of the package can change without changing the build configuration  — that is, without changing the GOOS, GOARCH, build tags, or experiment flags — just by looking at the package from the perspective of some other package in the same build.

@bcmills I must be misunderstanding something then, or there is some background context I'm missing.
The first sentence under "Proposed Solution" says:

I propose that it should not be possible to write tests in the same package as that being tested. That is, all tests must be in the external test package (e.g. foo_test to test package foo).

I regularly have tests in package foo (file foo_test.go), not package foo_test. If I understand this proposal, that would no longer be possible (without and added import "."). Maybe the implication was to use gofix to include import "."` in all such current situations?

It is unique to tests in that the API of the package can change without changing the build configuration

This sounds like a definition thing. But in my mind, testing is just another build configuration.
However, the crux of my issue is I think the following is a poor solution:

Consider this: with a given build environment (including tags), it is currently not possible to have a simple map from each package to type-checked information on that package.

This shouldn't be necessary for tools to setup in the first place. Secondly, it is possible by defining a test flag as a part of the build environment, though granted it does at least double the number of configurations needed, but certainly possible.
From the sound of it, I'm probably missing a bunch of context. But the premises of this need continues to concern me.

Related: https://github.com/golang/go/issues/6204

Like Axel, I'm not sure about the real benefit here. It sounds like it's intended to make tooling faster and simpler, which I am all for, but are tests really a problem?

To get an idea of the impact of this issue in a real situation, I looked at a portion of an existing code base to see what the impact of the current scheme is. I looked at the apiserver subdirectory inside github.com/juju/juju.
Inside that directory, there are 121 packages comprising 159317 lines of code in total, of which 54% is testing code. It takes 6m55s for me to run go test -c '^$' github.com/juju/juju/apiserver/....
I ran the Load/Visit/print code listed above on that directory. This was the result: http://paste.ubuntu.com/p/GVK5fyqq6n/
The duplication count due to internal test packages is quite high. Here's the list of packages and their duplication counts (how many versions of that package are required when building tests): http://paste.ubuntu.com/p/Pg5sggZpTp/
If we multiply the number of lines of code in each package by its duplication count (a crude measure, but perhaps a plausible proxy measure for the extra work done in the compiler), we see that an extra 263730 lines of code are used. If we include that as part of the original count, we get 423047 lines, or 2.65 times the original line count.
This it seems to me that the current scheme may be responsible for a significant amount of extra compilation time on larger projects.
More measurement would be needed to see how much time and/or memory this might actually save, but perhaps it might go some way towards reducing the overall overhead of running tests.

FWIW for duplication during tests the issue isn't only defining new APIs in _test.go files, but even just the concept of conditional compilation during tests. That is:

And, yes, the compiler would need to know that unexported symbols could be accessed in this particular case

Even if foo_test.go does not declare exported identifiers, it will result in a different compiled artifact that the compiler would conservatively have to recompile. i.e. for all of this to work, go test foo and go build foo would actually have to end up creating the same artifact containing the same code.
It's not 100% clear, but I assume you want to forbid _test.go files that contain a non-_test package declaration altogether, which would address this. But it does still mean that the compiler shouldn't do anything different when compiling a package-under-test.

FWIW, I'm not saying that we should do this, but another way to address all of these issues is to make test an actual build-tag. That has, of course, other downsides. But just with regular build tags, you would then get the property that they are specific to the execution of the go tool, instead of specific to a package. Again, not saying we should do this, just trying to open up the solution space :)

Yup. Why would it need to?

I understood that to be implied by "the compiler needs to know that unexported identifiers are accessed in this case" (this case being "having a test that accesses unexported identifiers"). Either way, at least it's clarified now :)

@rogpeppe

There's no such thing as a "test tag". Whether you're testing is orthogonal to the current set of tags.

I agree you are technically correct, there is not "test tag". But currently for the purposes of build caching, the test flag is an input into the cache key. I understand your primary motivation is to change this so tests compile independently of the rest of the package.
Have you done analysis on how allowing a import "." would impact complication of internal symbols? Today such symbols could be compiled away/in-lined entirely. But with this change I suspect any package level variable would be required to remain. Would this impact package symbols carried from imported packages that are only referenced from internal symbols?

This shouldn't be necessary for tools to setup in the first place. Secondly, it is possible by defining a test flag as a part of the build environment, though granted it does at least double the number of configurations needed, but certainly possible.

As I hope I've made clear in my replies above, you can't just use a single test flag - the number of configurations can be indefinitely high (which is why we have up to 15 copies of a given package in the real-world example above).

That's exactly my point. Thank you.
Currently, the number of build configurations can be indefinitely high in the current go/packages design. Adding -test to the build configuration will just make that higher. I agree.
So is the problem the various combinations that build tags and the test flag can be combined to get different symbols and -test is the most common offender, or is the problem that the current lexer/parser used for analysis doesn't handle multiple symbol versions for analysis? (I understand modifying the lexer/parser for analysis would be hard, but it would not contain pathological edge cases of explosion of build input combinations.)
I intend to not argue further on this point, I think my points been made. Thank you for listening, I hope I wasn't too long winded.

So is the problem the various combinations that build tags and the test flag can be combined to get different symbols and -test is the most common offender

I guess the problem is that a build tag applies to a complete call of a tool (you have to provide them in packages.Config), whereas the test-"flag" applies only to specific packages. If you start an analysis (or go test run…) at more than one package at the same time, you can have multiple sets of configs in the same run - but still only ever one set of build tags.
That's why I mentioned above that making test a full build flag (fully aware of the downsides) also solves this problem.

One thing that IMO makes this somewhat more confusing is the semantics of the packages-API. Load returns a slice of packages. If you range over that list and call Visit with each one in turn¹, every package will appear in the tree at most once - that is, Visiting each the *Packages individually provides you with an import-tree rooted at that package. So a tool that does that, when provided with a pattern (or list of packages), will behave the same as if you'd run it for each matching pattern individually (but be more efficient). However, the API is suggestive that you should pass the returned slice to Visit directly, which will then deduplicate packages and "lose" the information about what the root of the analysis was (instead just iterating over the transitive closure).
So, ISTM that we could at least document explicitly, that if you want the "every passed package its own analysis" semantics, you should range over the returned slice, whereas if you want the "anything in the transitive closure of dependencies" semantics, you should pass the slice to Visit (and be aware of this problem).

Modifying Rog's example:
func main() {
	pkgs, err := packages.Load(&packages.Config{
		Mode:  packages.LoadTypes,
		Dir:   ".",
		Tests: true,
	}, "example/...")
	if err != nil {
		log.Fatalf("cannot load packages: %v", err)
	}
	for _, pkg := range pkgs {
		if !strings.HasPrefix(pkg.ID, "example/") {
			continue
		}
		fmt.Printf("%s\n", pkg.ID)
		packages.Visit([]*packages.Package{pkg}, func(pkg *packages.Package) bool {
			if strings.HasPrefix(pkg.PkgPath, "example/") {
				fmt.Printf("\t%s\n", pkg.ID)
			}
			return true
		}, nil)
	}
}

Output:

```example/b
	example/b
example/c
	example/c
example/a
	example/a
	example/b
	example/c
example/b [example/b.test]
	example/b [example/b.test]
example/b_test [example/b.test]
	example/b_test [example/b.test]
	example/a [example/b.test]
	example/b [example/b.test]
	example/c
example/b.test
	example/b.test
	example/b [example/b.test]
	example/b_test [example/b.test]
	example/a [example/b.test]
	example/c
example/c [example/c.test]
	example/c [example/c.test]
example/c_test [example/c.test]
	example/c_test [example/c.test]
	example/a [example/c.test]
	example/b
	example/c [example/c.test]
example/c.test
	example/c.test
	example/c [example/c.test]
	example/c_test [example/c.test]
	example/a [example/c.test]
	example/b

Another thing I just thought of.
In the example I gave above, just building all the test binaries without running any tests took a long time (almost 7 minutes). I could imagine that as an optimisation, the Go compiler could potentially build several packages' tests into a single binary to speed up overall build overhead. This would be hard currently with many versions of the same package, but much more straightforward with the proposed scheme, where there's only one package for any given set of build tags.

Everything in test files, should not be exported !!!

I'd like to upvote this proposal. Huge CI builds of 1000s of go modules under test at once the overhead of rebuilding and caching each module in 100s configurations depending on the test it built for becomes quite significant. We use proprietary cross-language build system that supports go, but the complexity we face may be demonstrated by this Google's bazel code:
https://github.com/bazelbuild/rules_go/blob/master/go/private/rules/test.bzl#L445
Basically for every dependency of every test target we should decide whether it has transitive path to package under test and if so rebuild it (and cache). We cannot rebuild only immediate dependants.  Like Googlers say

Libraries imported by the external test that transitively import the
library under test must be recompiled too, or the linker will complain that
export data they were compiled with doesn't match the export data they
are linked with.

One may say that we ought to use native go toolchain, but it wouldn't solve a problem. There is no magic in native build: all the same variants of all the same packages are to be built and cached. Own build system just gives more control over process of building and caching at scale.


Strange bug in the DataTypeEntity

The DataTypeEntity is part of the data model, and all methods should be final - however, if the getName() method is declared final, then a NullPointerException is thrown when CircleServiceTest#testCreateAndReadCircle() is running.
Goal is to find the cause of the problem and, of course, fix it.

The bug was caused by the internal behavior of Hibernate and its proxy service which uses ByteBuddy. By first reading the the Object to compare against, the issue with the final method and the proxy was overcome.


Fix typo in bibliography

Fix make failing due to typo.
> make
scribble --pdf poof.scrbl
bibtex: Unknown citation "Borning86"

Thanks!


WAR-1781/WAR-1674: Unable to check api_response with regex pattern using verify_response keyword

Code changes:
Add regex verification support for jsonpath/xmlpath' comparison modes in 'verify_response' rest kw
Fix a bug in jsonpath comparison mode verification
(more details in WAR-1781/WAR-1674)
Execute 'wftests/warrior_tests/testcases/rest_functional_tests/tc_rest_verify_content_response.xml' to verify the fix. Regression logs are in WAR-1781.
WAR-1756 is raised to improve pylint score in rest_actions.py
PR for warriorframework repo : warriorframework/warriorframework#381

Pylint failure will be addressed in a separate ticket: https://github.com/warriorframework/warriorframework/pull/381#issuecomment-365511273


[WIP] Disable tls

@hzxuzhonghu: The following test failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

integ-local-tests_istio
47b93c8c5bd30aafe6da3d22696333f1fbb2f892
link
/test integ-local-tests_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@hzxuzhonghu: The following tests failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

integ-local-tests_istio
47b93c8c5bd30aafe6da3d22696333f1fbb2f892
link
/test integ-local-tests_istio

unit-tests_istio
47b93c8c5bd30aafe6da3d22696333f1fbb2f892
link
/test unit-tests_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@hzxuzhonghu: The following tests failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

integ-local-tests_istio
47b93c8c5bd30aafe6da3d22696333f1fbb2f892
link
/test integ-local-tests_istio

unit-tests_istio
47b93c8c5bd30aafe6da3d22696333f1fbb2f892
link
/test unit-tests_istio

lint_istio
47b93c8c5bd30aafe6da3d22696333f1fbb2f892
link
/test lint_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@hzxuzhonghu: The following tests failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

integ-local-tests_istio
47b93c8c5bd30aafe6da3d22696333f1fbb2f892
link
/test integ-local-tests_istio

unit-tests_istio
47b93c8c5bd30aafe6da3d22696333f1fbb2f892
link
/test unit-tests_istio

lint_istio
47b93c8c5bd30aafe6da3d22696333f1fbb2f892
link
/test lint_istio

release-test_istio
47b93c8c5bd30aafe6da3d22696333f1fbb2f892
link
/test release-test_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@hzxuzhonghu: The following tests failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

integ-local-tests_istio
47b93c8c5bd30aafe6da3d22696333f1fbb2f892
link
/test integ-local-tests_istio

unit-tests_istio
47b93c8c5bd30aafe6da3d22696333f1fbb2f892
link
/test unit-tests_istio

lint_istio
47b93c8c5bd30aafe6da3d22696333f1fbb2f892
link
/test lint_istio

release-test_istio
47b93c8c5bd30aafe6da3d22696333f1fbb2f892
link
/test release-test_istio

integ-mixer-k8s-tests_istio
47b93c8c5bd30aafe6da3d22696333f1fbb2f892
link
/test integ-mixer-k8s-tests_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@hzxuzhonghu: The following tests failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

integ-local-tests_istio
47b93c8c5bd30aafe6da3d22696333f1fbb2f892
link
/test integ-local-tests_istio

unit-tests_istio
47b93c8c5bd30aafe6da3d22696333f1fbb2f892
link
/test unit-tests_istio

lint_istio
47b93c8c5bd30aafe6da3d22696333f1fbb2f892
link
/test lint_istio

release-test_istio
47b93c8c5bd30aafe6da3d22696333f1fbb2f892
link
/test release-test_istio

integ-mixer-k8s-tests_istio
47b93c8c5bd30aafe6da3d22696333f1fbb2f892
link
/test integ-mixer-k8s-tests_istio

gencheck_istio
47b93c8c5bd30aafe6da3d22696333f1fbb2f892
link
/test gencheck_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@hzxuzhonghu: The following tests failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

integ-local-tests_istio
47b93c8c5bd30aafe6da3d22696333f1fbb2f892
link
/test integ-local-tests_istio

unit-tests_istio
47b93c8c5bd30aafe6da3d22696333f1fbb2f892
link
/test unit-tests_istio

lint_istio
47b93c8c5bd30aafe6da3d22696333f1fbb2f892
link
/test lint_istio

release-test_istio
47b93c8c5bd30aafe6da3d22696333f1fbb2f892
link
/test release-test_istio

integ-mixer-k8s-tests_istio
47b93c8c5bd30aafe6da3d22696333f1fbb2f892
link
/test integ-mixer-k8s-tests_istio

gencheck_istio
47b93c8c5bd30aafe6da3d22696333f1fbb2f892
link
/test gencheck_istio

integ-galley-k8s-tests_istio
47b93c8c5bd30aafe6da3d22696333f1fbb2f892
link
/test integ-galley-k8s-tests_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@hzxuzhonghu: The following tests failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

integ-local-tests_istio
47b93c8c5bd30aafe6da3d22696333f1fbb2f892
link
/test integ-local-tests_istio

unit-tests_istio
47b93c8c5bd30aafe6da3d22696333f1fbb2f892
link
/test unit-tests_istio

lint_istio
47b93c8c5bd30aafe6da3d22696333f1fbb2f892
link
/test lint_istio

release-test_istio
47b93c8c5bd30aafe6da3d22696333f1fbb2f892
link
/test release-test_istio

integ-mixer-k8s-tests_istio
47b93c8c5bd30aafe6da3d22696333f1fbb2f892
link
/test integ-mixer-k8s-tests_istio

gencheck_istio
47b93c8c5bd30aafe6da3d22696333f1fbb2f892
link
/test gencheck_istio

integ-galley-k8s-tests_istio
47b93c8c5bd30aafe6da3d22696333f1fbb2f892
link
/test integ-galley-k8s-tests_istio

integ-operator-controller-tests_istio
47b93c8c5bd30aafe6da3d22696333f1fbb2f892
link
/test integ-operator-controller-tests_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@hzxuzhonghu: The following tests failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

integ-local-tests_istio
47b93c8c5bd30aafe6da3d22696333f1fbb2f892
link
/test integ-local-tests_istio

unit-tests_istio
47b93c8c5bd30aafe6da3d22696333f1fbb2f892
link
/test unit-tests_istio

lint_istio
47b93c8c5bd30aafe6da3d22696333f1fbb2f892
link
/test lint_istio

release-test_istio
47b93c8c5bd30aafe6da3d22696333f1fbb2f892
link
/test release-test_istio

integ-mixer-k8s-tests_istio
47b93c8c5bd30aafe6da3d22696333f1fbb2f892
link
/test integ-mixer-k8s-tests_istio

gencheck_istio
47b93c8c5bd30aafe6da3d22696333f1fbb2f892
link
/test gencheck_istio

integ-galley-k8s-tests_istio
47b93c8c5bd30aafe6da3d22696333f1fbb2f892
link
/test integ-galley-k8s-tests_istio

integ-operator-controller-tests_istio
47b93c8c5bd30aafe6da3d22696333f1fbb2f892
link
/test integ-operator-controller-tests_istio

integ-pilot-k8s-tests_istio
47b93c8c5bd30aafe6da3d22696333f1fbb2f892
link
/test integ-pilot-k8s-tests_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@hzxuzhonghu: The following tests failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

integ-local-tests_istio
47b93c8c5bd30aafe6da3d22696333f1fbb2f892
link
/test integ-local-tests_istio

unit-tests_istio
47b93c8c5bd30aafe6da3d22696333f1fbb2f892
link
/test unit-tests_istio

lint_istio
47b93c8c5bd30aafe6da3d22696333f1fbb2f892
link
/test lint_istio

release-test_istio
47b93c8c5bd30aafe6da3d22696333f1fbb2f892
link
/test release-test_istio

integ-mixer-k8s-tests_istio
47b93c8c5bd30aafe6da3d22696333f1fbb2f892
link
/test integ-mixer-k8s-tests_istio

gencheck_istio
47b93c8c5bd30aafe6da3d22696333f1fbb2f892
link
/test gencheck_istio

integ-galley-k8s-tests_istio
47b93c8c5bd30aafe6da3d22696333f1fbb2f892
link
/test integ-galley-k8s-tests_istio

integ-operator-controller-tests_istio
47b93c8c5bd30aafe6da3d22696333f1fbb2f892
link
/test integ-operator-controller-tests_istio

integ-pilot-k8s-tests_istio
47b93c8c5bd30aafe6da3d22696333f1fbb2f892
link
/test integ-pilot-k8s-tests_istio

integ-distroless-k8s-tests_istio
47b93c8c5bd30aafe6da3d22696333f1fbb2f892
link
/test integ-distroless-k8s-tests_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@hzxuzhonghu: The following tests failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

integ-local-tests_istio
47b93c8c5bd30aafe6da3d22696333f1fbb2f892
link
/test integ-local-tests_istio

unit-tests_istio
47b93c8c5bd30aafe6da3d22696333f1fbb2f892
link
/test unit-tests_istio

lint_istio
47b93c8c5bd30aafe6da3d22696333f1fbb2f892
link
/test lint_istio

release-test_istio
47b93c8c5bd30aafe6da3d22696333f1fbb2f892
link
/test release-test_istio

integ-mixer-k8s-tests_istio
47b93c8c5bd30aafe6da3d22696333f1fbb2f892
link
/test integ-mixer-k8s-tests_istio

gencheck_istio
47b93c8c5bd30aafe6da3d22696333f1fbb2f892
link
/test gencheck_istio

integ-galley-k8s-tests_istio
47b93c8c5bd30aafe6da3d22696333f1fbb2f892
link
/test integ-galley-k8s-tests_istio

integ-operator-controller-tests_istio
47b93c8c5bd30aafe6da3d22696333f1fbb2f892
link
/test integ-operator-controller-tests_istio

integ-pilot-k8s-tests_istio
47b93c8c5bd30aafe6da3d22696333f1fbb2f892
link
/test integ-pilot-k8s-tests_istio

integ-distroless-k8s-tests_istio
47b93c8c5bd30aafe6da3d22696333f1fbb2f892
link
/test integ-distroless-k8s-tests_istio

integ-security-k8s-tests_istio
47b93c8c5bd30aafe6da3d22696333f1fbb2f892
link
/test integ-security-k8s-tests_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@hzxuzhonghu: The following tests failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

integ-local-tests_istio
47b93c8c5bd30aafe6da3d22696333f1fbb2f892
link
/test integ-local-tests_istio

unit-tests_istio
47b93c8c5bd30aafe6da3d22696333f1fbb2f892
link
/test unit-tests_istio

lint_istio
47b93c8c5bd30aafe6da3d22696333f1fbb2f892
link
/test lint_istio

release-test_istio
47b93c8c5bd30aafe6da3d22696333f1fbb2f892
link
/test release-test_istio

integ-mixer-k8s-tests_istio
47b93c8c5bd30aafe6da3d22696333f1fbb2f892
link
/test integ-mixer-k8s-tests_istio

gencheck_istio
47b93c8c5bd30aafe6da3d22696333f1fbb2f892
link
/test gencheck_istio

integ-galley-k8s-tests_istio
47b93c8c5bd30aafe6da3d22696333f1fbb2f892
link
/test integ-galley-k8s-tests_istio

integ-operator-controller-tests_istio
47b93c8c5bd30aafe6da3d22696333f1fbb2f892
link
/test integ-operator-controller-tests_istio

integ-pilot-k8s-tests_istio
47b93c8c5bd30aafe6da3d22696333f1fbb2f892
link
/test integ-pilot-k8s-tests_istio

integ-distroless-k8s-tests_istio
47b93c8c5bd30aafe6da3d22696333f1fbb2f892
link
/test integ-distroless-k8s-tests_istio

integ-security-k8s-tests_istio
47b93c8c5bd30aafe6da3d22696333f1fbb2f892
link
/test integ-security-k8s-tests_istio

integ-telemetry-k8s-tests_istio
47b93c8c5bd30aafe6da3d22696333f1fbb2f892
link
/test integ-telemetry-k8s-tests_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@hzxuzhonghu: The following tests failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

integ-local-tests_istio
47b93c8c5bd30aafe6da3d22696333f1fbb2f892
link
/test integ-local-tests_istio

unit-tests_istio
47b93c8c5bd30aafe6da3d22696333f1fbb2f892
link
/test unit-tests_istio

lint_istio
47b93c8c5bd30aafe6da3d22696333f1fbb2f892
link
/test lint_istio

release-test_istio
47b93c8c5bd30aafe6da3d22696333f1fbb2f892
link
/test release-test_istio

integ-mixer-k8s-tests_istio
47b93c8c5bd30aafe6da3d22696333f1fbb2f892
link
/test integ-mixer-k8s-tests_istio

gencheck_istio
47b93c8c5bd30aafe6da3d22696333f1fbb2f892
link
/test gencheck_istio

integ-galley-k8s-tests_istio
47b93c8c5bd30aafe6da3d22696333f1fbb2f892
link
/test integ-galley-k8s-tests_istio

integ-operator-controller-tests_istio
47b93c8c5bd30aafe6da3d22696333f1fbb2f892
link
/test integ-operator-controller-tests_istio

integ-pilot-k8s-tests_istio
47b93c8c5bd30aafe6da3d22696333f1fbb2f892
link
/test integ-pilot-k8s-tests_istio

integ-distroless-k8s-tests_istio
47b93c8c5bd30aafe6da3d22696333f1fbb2f892
link
/test integ-distroless-k8s-tests_istio

integ-security-k8s-tests_istio
47b93c8c5bd30aafe6da3d22696333f1fbb2f892
link
/test integ-security-k8s-tests_istio

integ-telemetry-k8s-tests_istio
47b93c8c5bd30aafe6da3d22696333f1fbb2f892
link
/test integ-telemetry-k8s-tests_istio

integ-multicluster-k8s-tests_istio
47b93c8c5bd30aafe6da3d22696333f1fbb2f892
link
/test integ-multicluster-k8s-tests_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

Thanks for stepping up! While this is WIP PR, would you mind adding some findings so far regarding #24028 ?

@incfly Could you show me how to do config_dump by the test framework? I want to get the configdump when it fails to verify my guess.

The framework will dump config dump when a test fails - see artifacts
section of the prow page. If you need to dump it when the test passes you
would need to modify the config. It should be a Dump() method somewhere
under pkg/test/framework
On Mon, Jun 1, 2020, 9:43 PM Zhonghu Xu<EMAIL_ADDRESS>wrote:

@incfly https://github.com/incfly Could you show me how to do
config_dump by the test framework? I want to get the configdump when it
fails to verify my guess.
—
You are receiving this because your review was requested.
Reply to this email directly, view it on GitHub
https://github.com/istio/istio/pull/24319#issuecomment-637268364, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAEYGXL7FG2LJMVDMO4BX53RUR7PJANCNFSM4NQLIIQQ
.

Great.
I normally would have to setup test env for my own cluster. The initial setup takes some effort, but once it's done, you can debug against cluster as normal k8s. adding log, sleep wait, change test. the roundtrip feedback is much faster than waiting CI.

@hzxuzhonghu: The following tests failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

integ-mixer-k8s-tests_istio
47b93c8c5bd30aafe6da3d22696333f1fbb2f892
link
/test integ-mixer-k8s-tests_istio

integ-security-k8s-tests_istio
47b93c8c5bd30aafe6da3d22696333f1fbb2f892
link
/test integ-security-k8s-tests_istio

integ-telemetry-k8s-tests_istio
47b93c8c5bd30aafe6da3d22696333f1fbb2f892
link
/test integ-telemetry-k8s-tests_istio

integ-multicluster-k8s-tests_istio
47b93c8c5bd30aafe6da3d22696333f1fbb2f892
link
/test integ-multicluster-k8s-tests_istio

integ-pilot-k8s-tests_istio
e31b3081d129c2a7b09c3ff7ef960456753ec291
link
/test integ-pilot-k8s-tests_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

I tried more than 20 times, but can not reproduce any failure in my local env

@hzxuzhonghu: PR needs rebase.

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

@hzxuzhonghu: The following test failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

integ-distroless-k8s-tests_istio
c2d2a62f161b2b4eb70ea461f79a40ea08415552
link
/test integ-distroless-k8s-tests_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@hzxuzhonghu: The following tests failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

integ-distroless-k8s-tests_istio
c2d2a62f161b2b4eb70ea461f79a40ea08415552
link
/test integ-distroless-k8s-tests_istio

integ-security-k8s-tests_istio
c2d2a62f161b2b4eb70ea461f79a40ea08415552
link
/test integ-security-k8s-tests_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@hzxuzhonghu: The following tests failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

integ-distroless-k8s-tests_istio
c2d2a62f161b2b4eb70ea461f79a40ea08415552
link
/test integ-distroless-k8s-tests_istio

integ-security-k8s-tests_istio
c2d2a62f161b2b4eb70ea461f79a40ea08415552
link
/test integ-security-k8s-tests_istio

integ-ipv6-k8s-tests_istio
c2d2a62f161b2b4eb70ea461f79a40ea08415552
link
/test integ-ipv6-k8s-tests_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

After #24874, i have not seen any failure.
ping @incfly @howardjohn

@hzxuzhonghu: The following test failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

integ-security-k8s-tests_istio
f104b0a4ea12798643438b115b7a20863301b3a3
link
/test integ-security-k8s-tests_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@hzxuzhonghu: The following tests failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

integ-security-k8s-tests_istio
f104b0a4ea12798643438b115b7a20863301b3a3
link
/test integ-security-k8s-tests_istio

analyze-tests_istio
f104b0a4ea12798643438b115b7a20863301b3a3
link
/test analyze-tests_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

/retest

ping @howardjohn , many users still claim failure on headless service  https://github.com/istio/istio/issues/24082

Addressed, may need to fix the e2e

@hzxuzhonghu: The following tests failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

analyze-tests_istio
f104b0a4ea12798643438b115b7a20863301b3a3
link
/test analyze-tests_istio

lint_istio
a4ac254d8b3c11ec69b785bb34054e8d492cd4ad
link
/test lint_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@hzxuzhonghu: The following tests failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

analyze-tests_istio
f104b0a4ea12798643438b115b7a20863301b3a3
link
/test analyze-tests_istio

lint_istio
a4ac254d8b3c11ec69b785bb34054e8d492cd4ad
link
/test lint_istio

unit-tests_istio
a4ac254d8b3c11ec69b785bb34054e8d492cd4ad
link
/test unit-tests_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@hzxuzhonghu: The following tests failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

analyze-tests_istio
f104b0a4ea12798643438b115b7a20863301b3a3
link
/test analyze-tests_istio

lint_istio
a4ac254d8b3c11ec69b785bb34054e8d492cd4ad
link
/test lint_istio

unit-tests_istio
a4ac254d8b3c11ec69b785bb34054e8d492cd4ad
link
/test unit-tests_istio

integ-ipv6-k8s-tests_istio
a4ac254d8b3c11ec69b785bb34054e8d492cd4ad
link
/test integ-ipv6-k8s-tests_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@hzxuzhonghu: The following tests failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

analyze-tests_istio
f104b0a4ea12798643438b115b7a20863301b3a3
link
/test analyze-tests_istio

lint_istio
a4ac254d8b3c11ec69b785bb34054e8d492cd4ad
link
/test lint_istio

unit-tests_istio
a4ac254d8b3c11ec69b785bb34054e8d492cd4ad
link
/test unit-tests_istio

integ-ipv6-k8s-tests_istio
a4ac254d8b3c11ec69b785bb34054e8d492cd4ad
link
/test integ-ipv6-k8s-tests_istio

integ-distroless-k8s-tests_istio
a4ac254d8b3c11ec69b785bb34054e8d492cd4ad
link
/test integ-distroless-k8s-tests_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@hzxuzhonghu: The following tests failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

analyze-tests_istio
f104b0a4ea12798643438b115b7a20863301b3a3
link
/test analyze-tests_istio

lint_istio
a4ac254d8b3c11ec69b785bb34054e8d492cd4ad
link
/test lint_istio

unit-tests_istio
a4ac254d8b3c11ec69b785bb34054e8d492cd4ad
link
/test unit-tests_istio

integ-ipv6-k8s-tests_istio
a4ac254d8b3c11ec69b785bb34054e8d492cd4ad
link
/test integ-ipv6-k8s-tests_istio

integ-distroless-k8s-tests_istio
a4ac254d8b3c11ec69b785bb34054e8d492cd4ad
link
/test integ-distroless-k8s-tests_istio

integ-security-k8s-tests_istio
a4ac254d8b3c11ec69b785bb34054e8d492cd4ad
link
/test integ-security-k8s-tests_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

In response to a cherrypick label: #24319 failed to apply on top of branch "release-1.6":
Using index info to reconstruct a base tree...
M	pilot/pkg/networking/core/v1alpha3/cluster.go
M	pilot/pkg/networking/core/v1alpha3/cluster_test.go
A	pkg/test/framework/features/README.md
M	tests/integration/pilot/cni/cni_test.go
M	tests/integration/security/mtls_first_party_jwt/strict_test.go
M	tests/integration/security/mtlsk8sca/strict_test.go
M	tests/integration/security/reachability_test.go
M	tests/integration/security/util/reachability/context.go
Falling back to patching base and 3-way merge...
Auto-merging tests/integration/security/util/reachability/context.go
CONFLICT (content): Merge conflict in tests/integration/security/util/reachability/context.go
Auto-merging tests/integration/security/reachability_test.go
CONFLICT (content): Merge conflict in tests/integration/security/reachability_test.go
Auto-merging tests/integration/security/mtlsk8sca/strict_test.go
Auto-merging tests/integration/security/mtls_first_party_jwt/strict_test.go
Auto-merging tests/integration/pilot/cni/cni_test.go
CONFLICT (modify/delete): pkg/test/framework/features/README.md deleted in HEAD and modified in disable tls for headless service when mtls is auto detected. Version disable tls for headless service when mtls is auto detected of pkg/test/framework/features/README.md left in tree.
Auto-merging pilot/pkg/networking/core/v1alpha3/cluster_test.go
Auto-merging pilot/pkg/networking/core/v1alpha3/cluster.go
error: Failed to merge in the changes.
Patch failed at 0001 disable tls for headless service when mtls is auto detected

In response to a cherrypick label: new issue created for failed cherrypick: #25523


tie_params doesnt work ?

I am trying to tie my length scales together using m.kern.rbf.tie_params('.*len') but I get the error: AttributeError: 'Add' object has no attribute 'tie_params'.
So, has the syntax changed or we cannot tie params anymore ?

No it is not implemented unfortunately. The easiest is to write a wrapper kernel, that does the tie itself.

On 3 Dec 2016, at 04:49, Kshitij Tiwari<EMAIL_ADDRESS>wrote:
I am trying to tie my length scales together using m.kern.rbf.tie_params('.*len') but I get the error: AttributeError: 'Add' object has no attribute 'tie_params'.
So, has the syntax changed or we cannot tie params anymore ?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

I am quite new to all this so would you mind suggesting how can I write a wrapper kernel ?

Here is how to write a kernel:
http://pythonhosted.org/GPy/tuto_creating_new_kernels.html
By wrapper kernel we mean a new kernel around the kernel you want to have, binding the lengthscales together (setting them to be equal to its lengthscale). Make sure you fix the lengthscales of the tied kernels and unlink their parameters (e.g. kern.unlink_parameter(kern.lengthscale)).
Sry for the inconvenience, but noone got around to actually getting the automatic tieing to work.


Remove hardcoded SID prefix (prd) from attributes keys

Fixes broken attribute fetching when SID != "PRD"

@fabriziosestito There are still some changes required in (2 entries at least): https://github.com/trento-project/trento/blob/main/web/templates/cluster_hana.html.tmpl
For example: https://github.com/trento-project/trento/blob/main/web/templates/cluster_hana.html.tmpl#L31

Ah yes i realized, you were too fast to review!


FID being returned incorrectly

This issue was imported from CodePlex
jtrobbins wrote 2012-02-02 at 14:38
I am finding that on a layer the FID is being incorrectly returned on selected items.
The user selects a range of items on the map, after this I get the selection using
featureLayer.Selection.ToFeatureList();
The problem is the returned list, for this layer at least, contains features with a FID == 0.
The orginal layer is fine since it has a theme which is rendered correctly and I can look though the dataset and see the FID's.
If I then edit one of the items in our application, which causes the feature to be updated, it work fine until that layer is loaded again.
The really odd thing is if I rebuild the layer i.e. delete and re-add all of the features, it exhibits the same behaviour yet other layers created with the same code are fine.
Without a FID it makes it impossible to allow the user to select/zoom to a specific feature when they have selected a number of features.

Not reproduced.


Defaut *.bin files from manufacturing ? If needed to reprogram them ...

Hello,
can you provide the defaut *.bin file from manufacturing or shipping if they are needed to reprogram the ESP32.
At the same, can you read only the ESP-32 and store the bin in new using the Flash tool software.
So that we can program, read back in file and do a binary compare of all the files...
Thanks and great ESP32.
Jp

Hi @JPB1JPB1,

can you provide the defaut *.bin file from manufacturing or shipping if they are needed to reprogram the ESP32.

Because the ESP32 chip itself doesn't have any on-board flash, we (Espressif) don't ship any factory image with the chip.
If the ESP32 comes in a module (like ESP-WROOM-32 or ESP3212) then there is flash onboard and it can be pre-loaded with something from the factory.
The module ESP-WROOM-32 is manufactured by us, I'll double check if any image comes pre-flashed onboard but I don't believe it does.
Other modules like ESP3212 are flashed with firmware by the module manufacturer (Ai-Thinker in the case of ESP3212), not by us.

At the same, can you read only the ESP-32 and store the bin in new using the Flash tool software.

You can use esptool.py (included in esp-idf) to save and restore flash from the command line:
For a 4MB flash chip (0x400000 bytes), you can run something like this in the esp-idf directory (using the same terminal you use to compile your esp-idf project, with IDF_PATH environment variable set as per the instructions):
Reset the module to bootloader mode, same as for regular esp-idf flashing. Then run:
source ${IDF_PATH}/add_path.sh
esptool.py --baud 920600 read_flash 0 0x400000 original_contents.bin

source add_path.sh extends your PATH to include th path to some tools shipped with esp-idf, including esptool.py.
read_flash reads the full 4MB of flash contents to a file. You will need a different (smaller) number if your module shipped with less than 4MB of flash.
Try a lower --baud rate if you get any errors. Default is 115200.

To write back:
esptool.py --baud 920600 write_flash --flash_mode dio --flash_size 4MB 0 original_contents.bin

So that we can program, read back in file and do a binary compare of all the files...

Sure, you can do this using the above steps. Also, the write_flash step used by esp-idf make flash also verifies the MD5 hash of all data written out, so it's very unlikely that write_flash will succeed but the data will be incorrect. However it can't hurt to be sure!

Ok thanks, Mr projectgus

does anybody have a dump of an ESP32-wroom32 factory image?
not the AT one.. the one originally flashed in the device


pythonPackages.antlr4-python2-runtime: init at 4.7.2

Motivation for this change
Breaking apart #62746
Things done

[X] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS)
Built on platform(s)

[X] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nix-review --run "nix-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[X] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Assured whether relevant documentation is up to date
[X] Fits CONTRIBUTING.md.

$ nix path-info -Sh ./result
/nix/store/1914j8xz98m1fh0zbhck6hc3hc7qx5xf-python2.7-antlr4-python2-runtime-4.7.2        95.4M

was included in #63169 closing


Support for React 18 ?

Any update?

I've no time to maintain the project at this time, if you want, you can fork the project contribute to handle the requirements.


Ensure consistency environment fixtures iso4

Description
The environment and environment_multi fixtures do not behave consistently. The environment fixture disables the AUTO_DEPLOY setting and sets the agent trigger method to push_full_deploy, while the environment_multi fixtures leave the environment settings to their default values. This PR fixes that inconsistency. Both fixtures will now disables the AUTO_DEPLOY setting and sets the agent trigger method to push_full_deploy.
Same PR as #3568, but now only for the ISO4 branch due to a merge conflict.
Self Check:

[ ] Attached issue to pull request
[x] Changelog entry
[x] Type annotations are present
[x] Code is clear and sufficiently documented
[x] No (preventable) type errors (check using make mypy or make mypy-diff)
[x] Sufficient test cases (reproduces the bug/tests the requested feature)
[x] Correct, in line with design
[ ] End user documentation is included or an issue is created for end-user documentation

Reviewer Checklist:

[ ] Sufficient test cases (reproduces the bug/tests the requested feature)
[ ] Code is clear and sufficiently documented
[ ] Correct, in line with design

Processing this pull request

Merged into branches iso4 in 6575178eabf7a01bcc4cec13b1cd476ed78323ed


View list products in pagination

Instead of return all products which exist in the DB, we just return products by page by page.
The number of products each page is up to you

Done by PR #113


Typescript Class to Object

Hi, is it possible to transform an instance of a TypeScript class to an instance of Object type?
I know that I can achieve this by first stringifying and then parsing as Object however I wonder if there is a direct method for that.
(Why I need that? Because I want to persist my User into mongoDB with JsonDiscriminatorValues.)
Thanks!

Hi, I believe serialize will do what you want. JSON.serialize(value:any):any is how you use it - give it a Typescript class and it will return a plain Javascript object (albeit one that has had the transformations from the decorators already applied).
Let me know if that doesn't fit your use case.


rename plugin to wallet

related to https://github.com/massalabs/thyra/issues/589#issuecomment-1497312408

can you also make the change for the frontend constants in web/html/constants.js ?


Roll engine in four steps (do not squash).

Folks with unrolled engine commits: @amirh @jonahwilliams @sbaranov @sjindel-google

I might be out of the loop - what is the plan with this and the other engine rolls?

Would be nice to list the engine commits this brings in in the PR description: git rev-list <hash1>..<hash2> --oneline

Added the rev list.

@jonahwilliams My plan is to land this as a rebase instead of a squash so the four engine revisions will be tested and benchmarked separately.


bump mockito version to latest and use bom

Issue
https://github.com/gravitee-io/issues/issues/8257
Description

Bump mockito version to latest version 5.1.1
Import mockito bom
Declare mockito-core, mockito-inline, and mockito-junit-jupiter in dependencies managment

Should it be a breaking change?

It is but it would not change the final version of the bom, which would still be a 4.0.0.

:tada: This PR is included in version 4.0.0-alpha.2 :tada:
The release is available on:

4.0.0-alpha.2
GitHub release

Your semantic-release bot :package::rocket:


Grafana Networking dashboards have wrong datasource hardcoded

What happened?
kube-prometheus/manifests/grafana-dashboardDefinitions.yaml has "wrong" datasource hardcoded in all "Networking"definitions.
Did you expect to see some different?
probably something like that "datasource": "$datasource", should be there instead of "datasource": "prometheus",
How to reproduce it (as minimally and precisely as possible):
You can deploy prometheus-operator chart from this PR https://github.com/helm/charts/pull/18564 and enjoy broken "Networking" dashboards everything else seems to be great
Environment

Prometheus Operator version: 0.33
Kubernetes version information: 1.16.2
Kubernetes cluster kind: hand-made pure linux + kubernetes environment

I have pushed fix https://github.com/helm/charts/pull/18375/commits/4e2e7e54fd2d3f41b6f253605600d83d13712fc9 to chart only. a.k.a "temporary fix until Upstream fixes own stuff"
I would say that it is littlbe bit strange bug... as some manifest have datasource variable and proper resources, others have nothing at all
Also good to discover that now i have to bootstrap grafana with plugin to properly display that dashboards

Yes this is indeed incorrect. Someone else already noticed this as well and fixed a couple other mistakes but not this one yet. Do you want to go ahead and fix it?

@brancz Unfortunately I don't have time and motivation to mess with jsonnet/libsonnet so hopefully someone more suitable for that job will be able to fix it in upstream.
In the meantime I will open similar issue in kubernetes-mixin repo.

Closing due to staleness. Please reopen if you think this is still relevant.


KAS: Set proxy, but exempt pod and service CIDR

The KAS needs the proxy settings to communicate with the cloud provider.
However, the egress transport it uses wraps another transport that
respects proxy settings which is why we need to excempt pod and service
CIDR of the guest cluster to not break Konnektivity.
I also tried to stop using the egress config and use the
konnektivity-socks5-proxy, but that breaks SPDY connections (exec,
port-forward).
Ref https://issues.redhat.com/browse/HOSTEDCP-333
I manually verified that all of exec, logs, apiservices and conformance tests that require the KAS to connect to the cloudprovider work.
/cc @csrwng

What this PR does / why we need it:
Which issue(s) this PR fixes (optional, use fixes #<issue_number>(, fixes #<issue_number>, ...) format, where issue_number might be a GitHub issue, or a Jira story:
Fixes #
Checklist

[ ] Subject and description added to both, commit and PR.
[ ] Relevant issues have been referenced.
[ ] This change includes docs.
[ ] This change includes unit tests.

/lgtm


docs: code snippets for concepts/combining_providers

This adds code snippets for the concepts/combining provider states page.
It enables toggling between code generation and the raw way.
To note: I did not use the actual dio package and instead would use a class I made for convenience (Not visible in documentation though). If this is not desired I can switch to dio :)

To note: I did not use the actual dio package and instead would use a class I made for convenience (Not visible in documentation though). If this is not desired I can switch to dio :)

It'd be better to use dio yes.
Could you do that?

Yes sure.
I'll make that change

Now using the actual dio package

Great, thanks!


Add ListExtensions.firstOrNull, lastOrNull, singleOrNull.

See https://github.com/dart-lang/collection/pull/312
For List we don't have to instantiate Iterator to implement these methods.

We could also let the existing operation on Iterable check for whether the Iterable has efficient length. If it has, it can do the same length checks as here, also for sets and queues, then use first/last on the Iterable for the value.

From performance perspective this seems bad. If we statically know that it is a List, why should we lose this information and invoke a more generic version, that then checks for the type to recover the lost information? Or do we know that VM will inline such methods, and rewrite by leaving only the branch for List types, practically removing the type check?

I don't think we know that anything will be inlined.
The extension on List will clearly be better, but will not work for Set or Queue, or on a list efficient is not statically known to be a list.
So we could do both.


Goals
Using a shared child object (to reduce the realm size on disk while adding) and adding it to a new parent without existing parents getting a notification.
Expected Results
I would not expect adding a child to object B to create a notification on object A
Actual Results
In this scenario object A gets a notification
Steps to Reproduce
Run the provided sample code. There is a collection listener on messages. When adding a second object, the collection listener indicates that new message has been inserted and the existing message has been modified. The modification in this case seems like a bug.
In the logs the insertion and modification are represented by this line:
~ Insertions: [1], deletions: [], modifications: [0]
Code Sample
sample_code.txt
Version of Realm and Tooling

Realm framework version: ?
Realm (3.20.0)
RealmSwift (3.20.0)
Xcode version: ?
Xcode 11.1
Build version 11A1027
iOS/OSX version: ?
ProductName:	Mac OS X
ProductVersion:	10.14.5
BuildVersion:	18F132
Dependency manager + version: ?
git version 2.8.1

This is a bug in UpdatePolicy.modified. We've failing to properly pass the update policy along when adding the objects in a List to the Realm, and it ends up using .all for the UserModel. The notification then reports that messages[0] has changed because messages[0].participants[0].user.email was assigned to (even though the value didn't actually change).
Until we fix this you can work around the problem by explicitly adding the objects contained in Lists to the Realm before adding the parent object. realm.add(users, update: .modified); realm.add(thread, update: .modified) suffices for the given repro case.

➤ Unito Sync Bot commented:
Transition made by Unito


Unable to make table scrollable. With fixed header

Version
Latest
Reproduction link
https://github.com/creativetimofficial/argon-dashboard-react
Operating System
Mac
Device
Mac
Browser & Version
Chrome latest
Steps to reproduce

Just using github repo
Added couple of more lines to table example
Trying to make table scrollable with fixed header bar when scrolling vertical and also fixed first column when horizontal scrolling.

What is expected?
Vertical Scrolling with fixed header.
Horizontal scrolling with  fixed first column
What is actually happening?
Header is scrolling with all rows.

Solution
I don't know. I am planning to purchase but saw this bug in free version.so i am stuck.
Additional comments

Hello there, @Robokishan ,
I really do not see how this is an issue with our product, we do not offer that functionality.
Please provide me with an actual reproduction link, the link you have given us, sends me to this repository.
Please provide me with some better steps, the 3rd steps tells me to try to make..., I really believe this step should be something like
4.  Add class Y on
6. Add the following CSS
7. ETC.
I need a step by step guide on how to reproduce your issue, but once again, I don't think this issue is caused by our product.
Best,
Manu


Uploading New App Logo/ App Logo Update #32

@meetxpress Squash the commits. Although your logo doesn't match the current UI, I'll make this PR eligible for hacktoberfest.

And @meetxpress don't create a PR until you are assigned for it.

Okay👍

Okay, I will keep that thing in my mind.
Actually, I have newly started contributing so I don't know how it works.


add "ssg" script to path

to be able to use this package via npm, there should be some exported path to be able to use from $PATH:

https://yarnpkg.com/en/docs/pnp

also, considering https://github.com/entu/ssg/issues/5 perhaps you want to split to two projects:

cli code for generate
fullblown electron app (that depends on the npm package)

please make release. this has no effect without actual release.

Done. Sorry for delay.

And will split it in next release


Doc links broken

From https://github.com/moonad/Formality , clicking on https://docs.formality-lang.org in the description leads to a notification that "We moved to Github!", and clicking on the provided link https://github.com/moonad/Formality/blob/master/DOCUMENTATION.md yields a 404.  So...where's the documentation?

Hi, sorry about the broken link, the documentation that previously linked to is here: https://github.com/moonad/Formality/blob/master/OLD_DOCUMENTATION.md
We are currently rewriting to the documentation to reflect the significant changes and improvements we've made to Formality over the past few months. This will be in https://github.com/moonad/Formality/blob/master/README.md and https://github.com/moonad/Formality/blob/master/FMC_SPECIFICATION.md for now, and eventually will be rendered as posts on moonad.org.
I have removed the link to docs.formality-lang.org (and unpinned the post on the Telegram channel), and will update with the moonad.org links when we have things live there.


Build errors on main using nightly compiler

apologies if this is a duplicate
i'm seeing build errors on main using nightly compiler
error[E0277]: the trait bound `HasRawWindowHandleWrapper: raw_window_handle::HasRawWindowHandle` is not satisfied
    --> crates/bevy_render/src/view/window.rs:131:48
     |
131  |                 render_instance.create_surface(&window.handle.get_handle())
     |                                 -------------- ^^^^^^^^^^^^^^^^^^^^^^^^^^^ the trait `raw_window_handle::HasRawWindowHandle` is not implemented for `HasRawWindowHandleWrapper`
     |                                 |
     |                                 required by a bound introduced by this call
     |
help: trait impl with same name found
    --> /home/dan/.cargo/registry/src/github.com-1ecc6299db9ec823/raw-window-handle-0.4.2/src/lib.rs:58:1
     |
58   | / unsafe impl<'a, T: HasRawWindowHandle + ?Sized> HasRawWindowHandle for &'a T {
59   | |     fn raw_window_handle(&self) -> RawWindowHandle {
60   | |         (*self).raw_window_handle()
61   | |     }
62   | | }
     | |_^
     = note: perhaps two different versions of crate `raw_window_handle` are being used?
note: required by a bound in `wgpu::Instance::create_surface`
    --> /home/dan/.cargo/registry/src/github.com-1ecc6299db9ec823/wgpu-0.11.1/src/lib.rs:1458:37
     |
1458 |     pub unsafe fn create_surface<W: raw_window_handle::HasRawWindowHandle>(
     |                                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ required by this bound in `wgpu::Instance::create_surface`

error[E0277]: the trait bound `HasRawWindowHandleWrapper: raw_window_handle::HasRawWindowHandle` is not satisfied
    --> crates/bevy_render/src/lib.rs:123:41
     |
123  |                 instance.create_surface(&handle)
     |                          -------------- ^^^^^^^ the trait `raw_window_handle::HasRawWindowHandle` is not implemented for `HasRawWindowHandleWrapper`
     |                          |
     |                          required by a bound introduced by this call
     |
help: trait impl with same name found
    --> /home/dan/.cargo/registry/src/github.com-1ecc6299db9ec823/raw-window-handle-0.4.2/src/lib.rs:58:1
     |
58   | / unsafe impl<'a, T: HasRawWindowHandle + ?Sized> HasRawWindowHandle for &'a T {
59   | |     fn raw_window_handle(&self) -> RawWindowHandle {
60   | |         (*self).raw_window_handle()
61   | |     }
62   | | }
     | |_^
     = note: perhaps two different versions of crate `raw_window_handle` are being used?
note: required by a bound in `wgpu::Instance::create_surface`
    --> /home/dan/.cargo/registry/src/github.com-1ecc6299db9ec823/wgpu-0.11.1/src/lib.rs:1458:37
     |
1458 |     pub unsafe fn create_surface<W: raw_window_handle::HasRawWindowHandle>(
     |                                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ required by this bound in `wgpu::Instance::create_surface`

For more information about this error, try `rustc --explain E0277`.
error: could not compile `bevy_render` due to 2 previous errors

Can you post the Cargo.lock file?

I could not reproduce with rustc 1.59.0-nightly (c5ecc1570 2021-12-15)

Can you post the Cargo.lock file?

good shout. cargo update has resolved it.


JUnit5 snippets

Any plans to support JUnit5 for generated snippets?

Sure.
I'm still creating some snippets from cases I've encountered, like:
@Test
@ParameterizedTest(name = "{0} plus {1} should be {2}")
@CsvSource({
	"0, 0, 0",
	"1, 0, 1",
	"1, 1, 2",
})
public void shouldAddTwoNumbers(int x, int y, int expectedSum) {
}

Feel free to open a PR with snippets that you would like to see or comment an example so I can put there.
Cheers

Sure.
I'm still creating some snippets from cases I've encountered, like:
@Test
@ParameterizedTest(name = "{0} plus {1} should be {2}")
@CsvSource({
	"0, 0, 0",
	"1, 0, 1",
	"1, 1, 2",
})
public void shouldAddTwoNumbers(int x, int y, int expectedSum) {
}

Feel free to open a PR with snippets that you would like to see or comment an example so I can put there.
Cheers

I've published a version to support JUnit 5.
Any problems or suggestions will be welcome.


[1pt] PR: Mask levee-protected areas from DEM

Masks levee-protected areas from DEM in branch 0 and two highest stream order branches to prevent slivers of inundation along the perimeter of levee-protected areas. Masking the DEM causes the same levee-protected area to be masked in the REM as well as the pixel catchments of any stream pixels in the leveed area. Closes #759
Additions

src/gms/

mask_dem.py: Masks levee-protected areas from DEM in branch 0 and two highest stream order branches
src/gms/delineate_hydros_and_produce_HAND.sh: Adds src/gms/mask_dem.py

Testing

Ran src/gms/mask_dem.py on branch 0 of HUC 12030109 to verify correct masking of DEM.
Ran Inundate_gms and Mosaic_inundation on HUC 12030109 to verify effect of masking DEM on REM and final inundation.

Screenshots

DEM (dem_meters_0.tif) with levee-protected areas masked

Depth raster (depth_12030109_0.tif): brown areas are low, positive (correct) depth values that will be inundated; green areas are high (incorrect) depth values that result from erroneous masking (fixed by #767) and will not be inundated after

Notes

Depends on #767 for proper results

I verified that branches with order less than max(order) - 1 are not being masked. In the example from 12030105 (max(order) = 6), the branch 0 REM (in gray) is masked in levee-protected areas (dotted) while the REM for order 3 branch<PHONE_NUMBER> (in color) is not masked in the leveed areas.

Keep the branch open (aka.. don't delete it). more changes and a separate PR are coming later.

I computed the proportion of levee-protected area in each of the categories

high: leveed area covered only by top two stream order branches (order_ >= max(order_) - 1)
low: leveed area covered only by the rest of the stream order branches (3 <= order_ < max(order_) - 1)
both: leveed area covered by both low and high stream order branches

The high areas are being masked and never inundated, the low areas are not masked, and for both: the leveed area is covered by both high (masked) and low (unmasked) branches. The both allow for situations like inundation by tributaries behind a levee that is protecting an area from inundation on the mainstem. The low are the "bad" ones because those levees are most likely protecting against the branch that we're failing to mask. Branch 0 (which would cover a HUC with high is not included in this analysis.
The resulting proportions are

high: 0.143
low: 0.103
both: 0.754

import os
import numpy as np
import geopandas as gpd
import pygeos as pg

def define_category(row):
    if row['Group_1'] == 'High':
        if row['Group_2'] == 'Low':
            return 'Both'
        else:
            return 'High'
    else:
        return 'Low'

hydrofabric_dir = '/data'
version_name = 'fim_4_0_9_2'

run_dir = os.path.join(hydrofabric_dir, 'outputs', version_name)

levee_protected_areas = gpd.read_file('/data/inputs/nld_vectors/Levee_protected_areas.gpkg')
levee_protected_areas['dissolve'] = 1
levee_protected_areas = levee_protected_areas.dissolve(by='dissolve')
wbd8 = gpd.read_file('/data/inputs/wbd/WBD_National.gpkg', layer='WBDHU8')

# # Intersect leveed areas with wbd to find leveed hucs
leveed_wbd8 = gpd.sjoin(levee_protected_areas, wbd8)
leveed_hucs = leveed_wbd8.HUC8.unique()

area_both = 0.
area_high = 0.
area_low = 0.

for n, huc in enumerate(leveed_hucs):
    print(f'{n+1}/{len(leveed_hucs)}: {huc}')

    wbd_file = os.path.join(run_dir, huc, 'wbd.gpkg')
    branch_polygons = os.path.join(run_dir, huc, 'branch_polygons.gpkg')
    if os.path.exists(branch_polygons) and os.path.exists(wbd_file):
        wbd = gpd.read_file(wbd_file, layer='WBDHU8')
        branch_polygons = gpd.read_file(branch_polygons, layer='branch_polygons')

        leveed = os.path.join(run_dir, huc, 'LeveeProtectedAreas_subset.gpkg')
        if os.path.exists(leveed):
            leveed = gpd.read_file(leveed, layer='LeveeProtectedAreas_subset')
        else:
            leveed = levee_protected_areas

        branch_polygons = gpd.clip(branch_polygons, wbd)
        leveed = gpd.clip(leveed, wbd)
        leveed['all'] = 1
        leveed = leveed.dissolve(by='all')

        max_order = branch_polygons.order_.max()

        branch_polygons.loc[branch_polygons.order_ >= max_order - 1, 'Group'] = 'High'
        branch_polygons.loc[branch_polygons.order_ < max_order - 1, 'Group'] = 'Low'

        branch_polygons = branch_polygons.explode()

        branch_polygons_groups = branch_polygons.dissolve(by='Group', as_index=False)
        if len(branch_polygons_groups.geometry) > 1:
            branch_polygons_union = gpd.overlay(branch_polygons_groups[branch_polygons_groups['Group'] == 'High'], branch_polygons_groups[branch_polygons_groups['Group'] == 'Low'], how='union')

            branch_polygons_union['Category'] = branch_polygons_union.apply(lambda row: define_category(row), axis=1)

        else:
            branch_polygons_union = branch_polygons_groups
            branch_polygons_union['Category'] = branch_polygons_groups['Group']

        round = np.vectorize(lambda geom: pg.apply(geom, lambda g: g.round(3)))
        leveed.geometry = round(leveed.geometry.values.data)
        branch_polygons_union.geometry = round(branch_polygons_union.geometry.values.data)

        levee_categories = gpd.overlay(leveed, branch_polygons_union, how='intersection')
        area_both += levee_categories[levee_categories['Category'] == 'Both'].area.sum()
        area_high += levee_categories[levee_categories['Category'] == 'High'].area.sum()
        area_low += levee_categories[levee_categories['Category'] == 'Low'].area.sum()

total_area = area_both + area_high + area_low

print(area_both/total_area, area_high/total_area, area_low/total_area)


maybe this will fix ads

closes https://github.com/ff14-advanced-market-search/saddlebag-with-pockets/issues/241

We should probably not load non-core app logic into root. :P
Do you have a list of issues I should check out @cohenaj194 ?


HellPot NextGen

Overview
I accidentally a whole coca cola bottle HellPot
This really is essentially a rewrite.

The entire configuration system has been rewritten
The logger has been rewritten
The main package (app) has been rewritten

~The only thing that remains untouched more or less is the heffalump core.~
This should resolve countless idiosyncrasies in configuration behavior.
Improvements

Much more random, harder to detect
Test cases

New Features

Allow regular expressions for matching disallowed user agents in addition to the current strings.Contains match functionality
Remote syslog output (tcp/udp)
CLI flags for all configuration values

New features by

@ginger51011 custom heffalump markov seed data

are scheduled to hitch a ride, pending further review and testing.
Slimfast
Further slimming of dependencies
Issues resolved

Resolves #140
Resolves #139

Mixing and matching configuration sources seems to be working well.

Screenshot

Great effort, really nice! Don't have that much time to sit and make a review right now, but fun to see great changes!

I still find myself really frustrated with the configuration system and ironing out all of the idiosyncrasies, even with Koanf vs Viper.
I've been toying with the idea of just doing the toml ourselves. I've been bashing my head against writing the decoder part of it the last few days, but the encoder works well enough (not that that's the important part though).
If there's anything I've learned while doing software development professionally, it's when to stop trying to use overly complex or just simply annoying dependencies that have been the source of endless bugs.
It usually ends up that the best course of action is to instead just write the functionality yourself. To the untrained it may sound like an unnecessary time sink, but one has to take into account the amount of time/money/unbridled rage caused by the dependencies in question. The scales tend to start tipping in a different direction after such considerations.
I digress, but it's an idea anyway. We'll see how it goes.


meta data updated

"nuxt-social-meta" package Required

The content of this PR is already included in the https://github.com/matter-labs/zksync-dapp-forced-exit/pull/4
Closing the current one.


Print functions without format

Is there any print function without formatting string, like StrCat but outputting to stdout?

We will be releasing a logging library soon, hopefully by the end of Q4 this year.
Is there a reason why any of the format string APIs or std::cout << StrCat(a, b, c) don't work?  As in something like
std::cout << absl::StreamFormat("%s", MyStringThing());

I'm using std::cout << StrCat(a, b, c) now, but I was trying to avoid allocating a string and output to stdout piecewise, like PrintF.

We don't have a StrCat that writes to stdout, and we don't have any plans to offer something like that, unfortunately.
I'm probably missing something really obvious, but I naively would have thought that anything you could pass into StrCat you could also pass directly to std::cout.  Are you using StrCat for hex formatting?
Personally, I wouldn't worry too much about a string allocation when writing to stdout because the cost of the allocation is probably much less than the cost of the I/O.  If the cost of the allocation is an issue for you and you'd still like to use something like StrCat, you do have the option of writing your own functions that have absl::AlphaNum parameters.  Something along these lines this should work:
void WriteToStdout(absl::AlphaNum a, absl::AlphaNum b, absl::AlphaNum c) {
  std::cout << a.Piece() << b.Piece() << c.Piece();
}

Clearly this isn't as convenient as having something you can use out-of-the-box, but you may find it useful in some situations.

I will use the WriteToStdout example above when necessary. Thanks.

Right now I can't figure out how to reuse my reader reader and writer so I outlook but come back again really honestly my Google Chrome is down I have no gigabytes on the hard drive on it will be it will probably be mid December before I get that up And

Only the icons up until the 30th and that way you guys could work on it I'll just keep it on my browser Thanks a lot

I’ll keep the browser up Until the 30th That way you guys can work on it Thanks a lot Send me an email if you Need to
Sent from Mail for Windows 10
From: Bart.Frankenfield
Sent: Thursday, November 15, 2018 2:39 PM
To: abseil/abseil-cpp
Cc: Bart.Frankenfield; Your activity
Subject: Re: [abseil/abseil-cpp] Print functions without format (#212)
Only the icons up until the 30th and that way you guys could work on it I'll just keep it on my browser Thanks a lot
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.


Multi-word tags don't work

If I click on a tag when I'm on the tag page it only jumps down to that section if the tags is a single word. For example, when I click on the Natural language processing tag, it doesn't jump down to that section: https://jss367.github.io/tags/#Natural language processing

Yup I see the problem, I will correct that asap :wink:
Thanks for reporting

@jss367
This was linked to #101 it should be solved now.

Awesome. Thanks!


Njalla API change

It appears that njalla silently changed their "id" parameter to be a string rather than int, which breaks most things that interact with it. (more details here: https://github.com/go-acme/lego/issues/1685)
It appears that this provider still creates the records but the output of terraform apply is filled with errors:
╷
│ Error: json: cannot unmarshal string into Go struct field Record.id of type int
│
│   with njalla_record_mx.mx,
│   on dns.tf line 73, in resource "njalla_record_mx" "mx":
│   73: resource "njalla_record_mx" "mx" {
│
╵

etc

Ugh, this is a pain in the ass. It requires changing the Go library as well, since this provider is really just a wrapper over that. The one good thing is that it seems infra might not need migrating as I initially thought, since Terraform already uses string IDs for keeping track of resources, and we were already converting the int IDs to str IDs in the provider, so here's to hoping this doesn't actually mean a breaking change in infra projects using this provider.

Hey, thanks for reporting. This should be fixed with the v0.10.0 release. If you haven't applied any changes it should be a painless update. Simply update the appropriate value in your Terraform infra:
terraform {
  required_version = "~> 1.2"

  required_providers {
    njalla = {
      source  = "Sighery/njalla"
      version = "~> 0.10.0"
    }
  }
}

Then run in the console:
terraform init -upgrade

To update the lock file, and that should do the trick. The IDs should still be the same, which means when you go plan it won't throw any errors, and detect no changes so nothing will be shown for changes.

If you've already tried to apply changes, and the records were created but not assimilated into the Terraform state, you should be able to, after updating to v0.10.0, import the records with terraform import njalla_record_txt.example-import example.com:12345, where the resource address and domain/ID will depend on your specific setup. There's a guide in the documentation on how to import which might be helpful. This link is generated off docs/guides/importing-record-resources.md.
If you tried to apply changes, and the records weren't created, then simply updating and trying to apply again should do the trick.

Looks like its working. Thanks so much!


Libxml rebuild

{package} {version} {:snowflake:}
Destination channel: {Snowflake | defaults}
Links

{ticket_number}
Upstream repository
Upstream changelog/diff
Relevant dependency PRs:

...

Explanation of changes:

...

Linter check found the following problems:
ERROR conda.cli.main_run:execute(125): `conda run conda-lint /tmp/abs_0anvqgv8go/clone` failed. (See above for error)
The following problems have been found:
===== WARNINGS =====

clone/recipe/meta.yaml:28: host_section_needs_exact_pinnings: Linked libraries host should have exact version pinnings.

===== ERRORS =====

clone/recipe/meta.yaml:16: pip_install_args: pip install should be run with --no-deps and --no-build-isolation.
===== Final Report: =====
1 Error and 1 Warning were found

Linter check found the following problems:
ERROR conda.cli.main_run:execute(125): `conda run conda-lint /tmp/abs_67mua1lu97/clone` failed. (See above for error)
The following problems have been found:
===== WARNINGS =====

clone/recipe/meta.yaml:28: host_section_needs_exact_pinnings: Linked libraries host should have exact version pinnings.

===== ERRORS =====

clone/recipe/meta.yaml:16: pip_install_args: pip install should be run with --no-deps and --no-build-isolation.
===== Final Report: =====
1 Error and 1 Warning were found

Linter check found the following problems:
ERROR conda.cli.main_run:execute(125): `conda run conda-lint /tmp/abs_8az8rjjq2b/clone` failed. (See above for error)
The following problems have been found:
===== WARNINGS =====

clone/recipe/meta.yaml:28: host_section_needs_exact_pinnings: Linked libraries host should have exact version pinnings.

===== ERRORS =====

clone/recipe/meta.yaml:16: pip_install_args: pip install should be run with --no-deps and --no-build-isolation.
===== Final Report: =====
1 Error and 1 Warning were found

Linter check found the following problems:
ERROR conda.cli.main_run:execute(125): `conda run conda-lint /tmp/abs_18ox_soiru/clone` failed. (See above for error)
The following problems have been found:
===== WARNINGS =====

clone/recipe/meta.yaml:28: host_section_needs_exact_pinnings: Linked libraries host should have exact version pinnings.
===== Final Report: =====
0 Errors and 1 Warning were found

Linter check found the following problems:
ERROR conda.cli.main_run:execute(125): `conda run conda-lint /tmp/abs_92smc8v7vx/clone` failed. (See above for error)
The following problems have been found:
===== WARNINGS =====

clone/recipe/meta.yaml:28: host_section_needs_exact_pinnings: Linked libraries host should have exact version pinnings.
===== Final Report: =====
0 Errors and 1 Warning were found

Linter check found the following problems:
ERROR conda.cli.main_run:execute(125): `conda run conda-lint /tmp/abs_cdsoyijeax/clone` failed. (See above for error)
The following problems have been found:
===== WARNINGS =====

clone/recipe/meta.yaml:28: host_section_needs_exact_pinnings: Linked libraries host should have exact version pinnings.

===== ERRORS =====

clone/recipe/meta.yaml:55: invalid_url: https://xmlsec.readthedocs.io/ : Not reachable: 403
===== Final Report: =====
1 Error and 1 Warning were found

Linter check found the following problems:
ERROR conda.cli.main_run:execute(125): `conda run conda-lint /tmp/abs_797r83ejbo/clone` failed. (See above for error)
The following problems have been found:
===== WARNINGS =====

clone/recipe/meta.yaml:28: host_section_needs_exact_pinnings: Linked libraries host should have exact version pinnings.

===== ERRORS =====

clone/recipe/meta.yaml:55: invalid_url: https://xmlsec.readthedocs.io/ : Not reachable: 403
===== Final Report: =====
1 Error and 1 Warning were found

Linter check found the following problems:
ERROR conda.cli.main_run:execute(125): `conda run conda-lint /tmp/abs_53ksu5k99w/clone` failed. (See above for error)
The following problems have been found:
===== WARNINGS =====

clone/recipe/meta.yaml:28: host_section_needs_exact_pinnings: Linked libraries host should have exact version pinnings.

===== ERRORS =====

clone/recipe/meta.yaml:55: invalid_url: https://xmlsec.readthedocs.io/ : Not reachable: 403
===== Final Report: =====
1 Error and 1 Warning were found

Linter check found the following problems:
ERROR conda.cli.main_run:execute(125): `conda run conda-lint /tmp/abs_edurquilcb/clone` failed. (See above for error)
The following problems have been found:
===== WARNINGS =====

clone/recipe/meta.yaml:28: host_section_needs_exact_pinnings: Linked libraries host should have exact version pinnings.

===== ERRORS =====

clone/recipe/meta.yaml:55: invalid_url: https://xmlsec.readthedocs.io/ : Not reachable: 403
===== Final Report: =====
1 Error and 1 Warning were found


ROX-12585, ROX-10890, ROX-12557, ROX-13153: Improve Github Actions usage

Description
Transferring changes for:

ROX-12585
ROX-10890
ROX-12557
ROX-13153

Pull requests:

https://github.com/stackrox/test-gh-actions/pull/57
https://github.com/stackrox/test-gh-actions/pull/56
https://github.com/stackrox/test-gh-actions/pull/55
https://github.com/stackrox/test-gh-actions/pull/54
https://github.com/stackrox/test-gh-actions/pull/52
https://github.com/stackrox/test-gh-actions/pull/51
https://github.com/stackrox/test-gh-actions/pull/50
https://github.com/stackrox/test-gh-actions/pull/47
https://github.com/stackrox/test-gh-actions/pull/46

The main changes are:

Automation of long-running cluster
Using composite and shared actions
Properties file for repository configuration (splits configuration from code)
Improved notifications for release engineer
Implementing recommendations by actionlint, change to new step output format

Checklist

~[ ] Investigated and inspected CI test results~
~[ ] Unit test and regression tests added~
~[ ] Evaluated and added CHANGELOG entry if required~
~[ ] Determined and documented upgrade steps~
~[ ] Documented user facing changes (create PR based on openshift/openshift-docs and merge into rhacs-docs)~

If any of these don't apply, please comment below.
Testing Performed
Development and testing performed in test-gh-actions repository.
In addition to reviewing your code, reviewers must also review your testing
instructions and make sure they are sufficient.

/retest-required


Update references from BAMM to SAMM

Signed-off-by: Johannes Kristan<EMAIL_ADDRESS>Description
Updates references in the README from BAMM to SAMM and adds a reference to the currently used CLI version.

LGTM

@bs-jokri  fine for me.