-
Notifications
You must be signed in to change notification settings - Fork 167
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
tmp dir needed on ubuntu 1604 and fedora23 #873
Comments
Isn't this just because #785 still hasn't landed? |
i.e. dup of #833 ? |
So that's landed now, I think the ansible scripts would need to be rerun on the machines. |
ping on this for ubuntu. Have the ansible scripts not been run yet? I'm still seeing failures in CITGM |
:( |
Hey all.. this is still not fixed, and has not been fixed for months I'm getting really frustrated as this is breaking our ability to have green CI runs with CITGM. Can someone please prioritize this /cc @nodejs/tsc |
What's the purpose of the |
You have nodejs_build_test access don't you @MylesBorins, your ability to execute on this is pretty much the same as ours. Someone's either going to have to manually log in to each of these machines to make this directory or run parallel-ssh or Ansible across them all. The blocker here is having a person with the time to work through all of the hosts but everyone with nodejs_build_test is equally able to do this. |
I'll pick this up. There might be a "take home" here, in that maybe whomever lands an ansible change should run the scripts. Alternatively we could have point man for parts of the inventory. |
Alternatively the CitGM job could just do a |
yes! let's just do that eh? |
👍 |
The reason to TSC-Agenda item was added was that this is something that has been brought up for months. It was last brought up in #833 which was claimed that a fix was to be landed in #785. An early request #658 was also closed, an issue opened in March. To be honest I have never been on boarded to using our ansible scripts and I don't feel comfortable doing a mass update of our infrastructure because of that. This did not seem like a laborious request for help, and is blocking our ability to test I think that we should be having a conversation both at the WG + TSC level about why a request like this has remained unresolved for over 6 months. |
Anyone know if |
It comes from /cc @mcollina |
Can that line be replaced with |
Interesting, but I still don't see where |
Those things are pulled from node core. At some point we discussed changing that line or fixing CI, and the general sentiment was that fixing CI was the best path forward. I can dig up the issue if you'd like. However I prefer changing as little as possible in our tests. |
OK, so there's a bunch of this kind of things in our node-test-commit-XXX configs:
I don't know the history of those (wasn't me so I have no clue why they were set). But there's nothing in the citgm jobs for it and there's no Personally I'd like to keep our specific hardware config to a minimum as it keep on being a pain, and if that means pushing more into Jenkins jobs then so be it (for the record, that sucks too cause the config isn't public and only a few of us can even see it! But it's one thing that GitHub-hosted pipeline jobs could solve for us). |
Just had a brain-wave before I drop off to bed. We have this check-java-version job that we've been using to get ourselves up to Java 8 on all our Jenkins machines and it has all our non-Windows machines wired up to it, so I just stuck |
Might be one caveat:
So any code in the tested modules that looks up NODE_TEST_DIR will take the default. So we should either set it in the job, or remove it from openrc.initd
|
It runs on our Windows machines too. |
@MylesBorins this seems like the issue then. You're one of the senior members of the Build WG, and you're not comfortable updating our machines. That's not a judgement, I'm not comfortable doing it either, and I'm not sure anyone else is. |
From my understanding from the discussion over the last couple of meetings, this is resolved in the specific but the general concern about our confidence in our Ansible scripts remains so I've opened that up as a separate issue @ #959 |
Still seeing errors like
Please halp
The text was updated successfully, but these errors were encountered: