Closed sophia-guo closed 1 month ago
@steelhead31 Can you take a look at this please since I know you've lookd at other permissions related issues on Windows in recent months? I logged into the machine but the keyboard layout is a bit messed up (It was initially showing that it was set to Welsh but it's worse than that - both as the admin and jenkins users - and switching it back didn't seem to help) - would be good to know if that happens for you too.
It does look like the permissions on the mentioned directory are messed up though so that it can't be written to by the jenkins user - have any changes occurred recently on this machine?
@sxa I'll take a look, nothing has changed as far as Im aware, though I have noticed all of the windows test machines switching to a welsh keyboard layout... haven't noticed it on a build machine though. The permissions issue hints of the same thing occurring on the ibmcloud machine...
Just investigating, the welsh keyboard layout is unusual, in that windows doesn't recognise it as an installed language... so I've added it, and then removed it to ensure that only the default, US layout is available... I'll run a set of tests, to see if something in the test suite, is causing it to be installed / enabled.
The permissions issue is slightly more unusual..
And this..
Top level directory has correct security descriptors, problem is only visible in anything below C:\Users\jenkins\workspace\Grinder\aqa-tests
Interestingly the TKG directory cant be deleted by Administrator, as its owned by jenkins.. and jenkins cant delete it because it doesn't have administrator permissions.
I guess this is most likely something caused by the reproducible build job in Grinder, since that is the last one that managed to create anything under aqa-tests
, although I can't imagine why that would have caused something like this 🤔
I wonder if we've got a chmod
somewhere in the process somewhere that's affecting things. I guess the test will be to try a re-run of the original job to see if it recurs on that machine after you've cleaned up the permissions.
In progress, running parallel jobs on 2022-2 and 2019-1 to see what the end result is.. :)
Permissions issue hasnt occured on either machine :man_shrugging:
@sophia-guo I've fixed the issue, and Im unable to replicate ( I've run two consecutive grinders ), is that sufficient for you to continue, or do you still require access ?
Thanks @steelhead31 . Trying to see if it's good https://ci.adoptium.net/view/Test_grinder/job/Grinder/9886/
Looks good. Will close this one.
NOTE: THIS ISSUE SHOULD NOT BE CLOSED BY THE ORIGINATOR IF ACCESS IS GRANTED. When the access is no longer needed please add a comment and a member of the infrastructure team will revoke it and close the issue.
Required access level (Delete as appropriate). Note that you should only request the minimum level that is required to solve your problem
System for which access is needed: https://ci.adoptium.net/computer/test%2Dazure%2Dwin2019%2Dx64%2D1/
Grinder run for windows reproduciable comparing hit the issue
can not delete workspace
https://ci.adoptium.net/view/Test_grinder/job/Grinder/9863/console,Same run on https://ci.adoptium.net/computer/build-azure-win2022-x64-2/ didn't get the issue https://ci.adoptium.net/view/Test_grinder/job/Grinder/9876/
Need to clean workspace to investigate.
Please explain why you need this access including whether it is a temporary or permanent request: