Status/tab on ci.nodejs.org

[nschonni]

Maybe not possible since I don't think this is leveraging any of the other Jenkins setup from the nodejs/build setup. Was just thinking that it would be nice to have a tab there for the unofficial jobs to see the status over just looking at the logs folder as they go. That might not be possible though, without the jobs looking more "official" than you want.

[richardlau]

Yeah this project doesn't use Jenkins (ci.nodejs.org or otherwise) at all -- it runs as described (https://github.com/nodejs/unofficial-builds#how) via the Docker containers and shell scripts in this repository and triggered by systemd timers and https://www.npmjs.com/package/github-webhook.

[rvagg]

it wouldn't be hard to script up and plug in to the existing process; it's largely bash and cron strung together so wouldn't be hard to insert a bit more of the same to get you a status page that's updated as it progresses in real-time or near real-time

[sxa]

@rvagg Has there been much discussion about potentially using jenkins for running/triggering the unofficial builds? Is it related to the ACLs being differnet between the people maintaining the unofficial-builds server and who has access to jenkins jobs?

[rvagg]

@sxa no, but one of the intentions of this project was to keep it lightweight (technically and in terms of SLA) and arms-length from the existing Build team. It's "unofficial" in multiple senses. If we start tangling it up with the rest of the infra are we signing up for more maintenance burden for the team? At the moment it's a bit like nodejs/snap, if it breaks, then the Build team doesn't have to urgently scramble to fix it, we can just hand-wave and say "someone will fix it when they have time, we're not committed to a strong SLA for this thing".

But, you're welcome to steer it in alternative directions, just be aware of the maintenance costs and the fact that the vast bulk of infra/build work is falling on IBM/RH right now and you're signing up for even more of that if you want to integrate and embrace.

[sxa]

Wow - this discussion was from a year ago now :-) I would say that yes I'm happy to try and steer it forward so it is run via jenkins if there is no real objections - from my perspective it'll be easier to monitor and spot for failures if we use the same fundamental automation for running these as we do for everything else unless there is a strong objection. It shouldn't need to be too much more than a wrapper around the existing stuff, and use jenkins to manage the queueing.