On Tue, Sep 17, 2024 at 4:08 AM twp...@gmail.com wrote:
>
> However, I want to make go test cache's behavior more correct for a case
> where it is currently incorrect for no measurable performance penalty. What
> are the reasons for *not* doing this?
We do not want to record all aspects of the
On Tue, Sep 17, 2024 at 3:26 AM twp...@gmail.com wrote:
>
> > Should work, AIUI, even with the issues you mention. Or is there something
> > else going on that I'm unaware of?
>
> The problem is not running the tests. The problem is that the test cache is
> not invalidated correctly.
We are sug
Hi can you file an issue on the github issue thread list? We can follow up
there
Arkadiusz Drabczyk 于2024年9月16日周一 21:10写道：
> On Fri, Sep 13, 2024 at 03:16:28AM -0700, Fulton Shaw wrote:
> > Take a look at https://github.com/xhd2015/xgo#incremental-coverage
> >
> > Example incremental code covera
I think you are probably going to get better results by just filing a
proposal. That's the normal process which will end in a definite result one
way or the other, while mailing list threads tend to go in circles,
eventually.
On Tue, 17 Sept 2024 at 13:08, twp...@gmail.com wrote:
>
> On Tuesday,
On Tuesday, September 17, 2024 at 12:44:42 PM UTC+2 Stephen Illingworth
wrote:
If the only problem is that the cache is getting in the way then you can
run the tests such that test cache is not used. The idiomatic way is to use
-count=1 on the test command line
I would do this:
go test -coun
If the only problem is that the cache is getting in the way then you can
run the tests such that test cache is not used. The idiomatic way is to use
-count=1 on the test command line
I would do this:
go test -count=1
And then:
go test
On Tuesday 17 September 2024 at 11:25:40 UTC+1 twp...@g
> Should work, AIUI, even with the issues you mention. Or is there
something else going on that I'm unaware of?
The problem is not running the tests. The problem is that the test cache is
not invalidated correctly.
On Tuesday, September 17, 2024 at 11:52:35 AM UTC+2 Axel Wagner wrote:
On Tue,
On Tue, 17 Sept 2024 at 10:33, twp...@gmail.com wrote:
> umask cannot be set in subtests for two reasons:
> 1. It is a process-wide global variable stored by the operating system.
> Changing the umask in a test changes the umask for the entire process, i.e.
> it changes the umask for all tests.
>
> I interpret that to mean you are changing the umask before running `go
test`. That is, you might run `go test` with different umask values and
don't want the cached results to ignore the umask value. As did Ian if I
correctly understood their reply. The discussion then evolved into how a
spec
You wrote earlier:
> Currently changing the umask does not invalidate go test's cache, so I
get incorrect test results if I change the umask and re-run go test
I interpret that to mean you are changing the umask before running `go
test`. That is, you might run `go test` with different umask value
umask cannot be set in subtests for two reasons:
1. It is a process-wide global variable stored by the operating system.
Changing the umask in a test changes the umask for the entire process, i.e.
it changes the umask for all tests.
2. It is not possible to set and restore the umask atomically. T
11 matches
Mail list logo
