Can we copy artefacts for the fanned Windows jobs instead of a private git repo?

[sxa]

As part of diagnosing a disk space issue on the CI server it was brought to my attention that we're using a private git repository hosted on one of our servers for copying the binary output between the windows compilation and test jobs.

This feels to me like unnecessary complexity and I'm wondering whether it would make sense to use the jenkins artefact from the compile job and pull from that directlry into the test jobs instead of going via that git repository. My understanding is that we were doing the same for the arm32 fanned jobs before we switched them over to using the aarch64 hosted systems for those (since there was no reason to fan them in that situation)

Since I'm not aware of the history of why we chose to use a git repo for the binaries, does anyone have the history of the reasoning, or is there a good reason not to consider using the standard jenkins artefact process instead? @joaocgreis @nodejs/build

[richardlau]

My understanding is that we were doing the same for the arm32 fanned jobs before we switched them over to using the aarch64 hosted systems for those (since there was no reason to fan them in that situation)

We still are since we're still cross-compiling for arm32.

[richardlau]

My understanding is that we were doing the same for the arm32 fanned jobs before we switched them over to using the aarch64 hosted systems for those (since there was no reason to fan them in that situation)

We still are since we're still cross-compiling for arm32.

Or to be more precise, we're doing both -- cross compiling and an all-in-one job. For the released binaries we still cross compile which is why the cross compile job is still being run in the test CI.

[sxa]

Or to be more precise, we're doing both -- cross compiling and an all-in-one job. For the released binaries we still cross compile which is why the cross compile job is still being run in the test CI.

I thought we'd disabled the fanned version - clearly not. Is there any particular reason to retain it? Maybe to verify that the cross-compiled one we do in the release CI will work? I suppose the other question is whether we should move the release one to be running in an arm32 container (Not sure if we had a reason to avoid moving that one across or if we just never got around to it)

[richardlau]

I thought we'd disabled the fanned version - clearly not. Is there any particular reason to retain it? Maybe to verify that the cross-compiled one we do in the release CI will work?

Yes, this.

I suppose the other question is whether we should move the release one to be running in an arm32 container (Not sure if we had a reason to avoid moving that one across or if we just never got around to it)

The main reason it hasn't been moved is it would require reengineering parts of the iojs+release job. You'd also need to identify a suitable arm32 container to use (RHEL 8 doesn't support armv7) and consider what version of glibc is being linked against.

[joaocgreis]

I did set up the fanned jobs a long time ago, and I can't say I remember all the details. It's possible that Jenkins artifacts simply didn't have enough functionality at the time for what we needed.

Keeping large files in git comes with some challenges, which were initially mitigated because we used a repo on GitHub. But it grew too much, and we were asked to move it out. The simplest solution was moving them to the jenkins-workspaces (they're all set up and ready, the specific jenkins-workspace to use is controlled by a variable in Jenkins). With the current set of cleanup scripts, AFAIK, things have been stable.

Note that git has some relevant advantages: you need to match source code with binaries, and it's not very likely to have mismatches this way. Also, the jobs would need to use git anyway, this just reuses that complexity on the Jenkins side.

If you have the bandwidth for that, feel free to experiment with a copy of the job! Some challenges are supporting resumed jobs, allowing the output of the compile jobs to run on multiple test jobs, minimizing the overall execution time, and having the job run reliably. Also, we're using git explicitly instead of the git plugin because it had an issue with change logs (not sure if build time or disk space) that would get worse as the job accumulated runs, and the only way to fix was to completely delete the job and create a new one. I don't know if that's fixed now.

[sxa]

Thanks for confirming the reasons @joaocgreis ... I don't have a lot of spare bandwidth but I'll look at adjusting it as a "spare time" task. I do something similar on another project using Jenkins so it should be feasible 🤞

[github-actions[bot]]

This issue is stale because it has been open many days with no activity. It will be closed soon unless the stale label is removed or a comment is made.

[sxa]

This fell off my radar completely but I'd still like to see it done so posting this to keep the issue alive

Noting that a fanned job may be useful if we wish to add riscv64 into the main CI jobs since we have access to quite a few machines but they're all relatively slow.