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 -count=1 <umask tests>
And then:
go test <other tests>
I am aware that I can work around go test cache's incorrect behavior by
disabling the cache. This is annoying for several reasons:
* I have to manually maintain a list of tests that are affected by the
umask.
* I have to run go test twice.
* I don't get the speed-ups of caching when the caching should work, which
slows down my development cycle.
Note that all tests that write files are affected by umask, even if many
people don't realize this. To demonstrate this, find a project that calls
testing.T.TempDir() and run:
$ umask 777
$ go test ./... -count=1
The odds are that the tests will fail.
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?
On Tuesday 17 September 2024 at 11:25:40 UTC+1 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.
On Tuesday, September 17, 2024 at 11:52:35 AM UTC+2 Axel Wagner wrote:
On Tue, 17 Sept 2024 at 10:33, twp...@gmail.com <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.
2. It is not possible to set and restore the umask atomically. This makes
it inherently racy for concurrent programs.
I might be misunderstanding something, but neither of these seems to
actually be a problem. Tests are not run concurrently, unless explicitly
requested by calling `t.Parallel()`. The same goes for sub tests, I
believe. So, simply doing
func TestOne(t *testing.T) {
defer syscall.Umask(syscall.Umask(0))
// test goes here
}
func TestTwo(t *testing.T) {
defer syscall.Umask(syscall.Umask(0777))
// test goes here
}
To learn more about umask, and why it is special, please read the man page
<https://man7.org/linux/man-pages/man2/umask.2.html>.
On Monday, September 16, 2024 at 5:34:29 PM UTC+2 Jason Phillips wrote:
Why can't it be set within subtests? Note that subtests (like regular
tests) aren't run in parallel unless you explicitly call t.Parallel().
On Friday, September 13, 2024 at 6:35:15 PM UTC-4 twp...@gmail.com wrote:
> Personally, I would approach this kind of thing by writing a test that
sets the umask to various different values and invokes subtests with
each umask value.
I would love to do this but umask is a process global (as far as I
understand it) and so can't be set within subtests.
On Saturday, September 14, 2024 at 12:33:19 AM UTC+2 Ian Lance Taylor wrote:
On Fri, Sep 13, 2024 at 3:03 PM twp...@gmail.com <twp...@gmail.com> wrote:
>
> tl;dr: umask is a system-wide global that affects go tests and should be
considered when validating go test's cache.
>
>
> Motivation:
>
> I'm the author of a popular open source project that writes files to the
user's home directory and cares about getting exact file permissions
correct. The file permissions depend on the the current umask setting. As
umask is a process global variable, it cannot be set for individual tests,
and so separate tests are needed for different umasks.
>
> 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.
>
>
> Suggested solution:
>
> Include umask as an op in go test's id calculation.
>
>
> Next steps:
>
> * Is this something that the Go project would consider?
> * If so, I would be happy to submit a CL.
Personally, I would approach this kind of thing by writing a test that
sets the umask to various different values and invokes subtests with
each umask value. That way the test is independent of the external
environment.
In general our approach has been that if your test intrinsically
depends on the external environment, then you should run it with
-test.run=1 to disable the test cache.
Ian
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to golang-nuts...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/c9dcf1bb-25ae-4e58-8714-66325077c2d1n%40googlegroups.com
<https://groups.google.com/d/msgid/golang-nuts/c9dcf1bb-25ae-4e58-8714-66325077c2d1n%40googlegroups.com?utm_medium=email&utm_source=footer>
.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/27617075-a38b-4e01-8412-b290aab3f906n%40googlegroups.com.
