Giters

nodejs / build

Better build and test infra for Node.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

LFIT Jenkins transition to GHA POC

vvalderrv opened this issue · comments

commented

While acknowledging that transitioning all pipelines and jobs to GitHub Actions (GHA) may not be practical, recent GH changes to self-hosted and free runners along with container options create opportunities for a more extensive migration of pipelines and jobs. With this in mind, we would like to do a POC for the BWG and are requesting admin access to ci.nodejs.org and github.com/nodejs

Jenkins
username: lfreleng
email address: collab-it+lfreleng@linuxfoundation.org

GitHub
username: lfreleng-github

Thank you,
Vanessa Valderrama
LF Release Engineering

commented

@vvalderrv Our Jenkins is authenticated via GitHub -- neither

appear to be existing GH accounts. @mhdawson did create a GitHub team, nodejs/LinuxIT-infra-temp, that you and @ryanaslett are in but I think at the moment that's read only access. @nodejs/build I'd be open to giving that team, or a lfreleng GH account (if created), admin permissions on Jenkins for this request as long as the TSC agrees to granting the necessary permissions on the GHA side -- WDYT?

Requests for admin access to github.com/nodejs would need to be made in https://github.com/nodejs/admin/issues as that would be a TSC, rather than Build WG, decision.

commented

Some old discussions around this #2247

commented

My understanding that in earlier discussions with Linux IT on this topic it was understood that moving to GitHub actions is not feasible/the right way to go due to dependencies on specific os versions and limited OS support in GitHub.

From my perspective effort would be better invested in work to start managing some of the existing servers, possibly those hosting the downloads for the Website. Having said that, it's only my opinion as one of the build WG members. If other members support and are willing to invest their time to help move it forward then I'm not going to block. The Linux IT team already asked me about this, so just adding the context that me sharing this opinion is not a surprise.

commented

@

We have different resources working on the Jenkins to GHA POC so we'd prefer admin for the lfreleng-github account if possible.

I will open a separate issue for GH access.

Thank you,
Vanessa

commented

Just to clarify, what is the reason for choosing to investigate this? It's not clear from the description. Presumably there is some benefit that is perceived in having an alternate solution to Jenkins over and above it just being "feasible" to do that now, especially if people are being given the time to work on it.

Is there a problem you are looking to solve?

commented

@nodejs/build I'd be open to giving that team, or a lfreleng GH account (if created), admin permissions on Jenkins for this request as long as the TSC agrees to granting the necessary permissions on the GHA side -- WDYT?

I think that we are already trusting them to help us manage infra transitions (like #3615 impacting release machines). In my opinion the access level requested (admin) is justified to run a POC to check the availability to migrate workload from Jenkins to GItHub Actions. This POC won't modify any existing workflow (AFAIK) and it will run on parallel to the existing pipelines.

I am +1 to provide admin level for https://ci.nodejs.org/ to run this POC and re-evaluate the access level required once the POC is concluded.

commented

As we develop our transition plan, we're actively seeking opportunities to streamline our vendor relationships by consolidating services wherever feasible. One avenue for achieving this consolidation is through maximizing our utilization of GHA. By leveraging GHA to its fullest extent, we aim to reduce reliance on external vendors and simplify our tooling landscape.

This approach aligns with the STF initiative to consolidate vendors (in this case, cloud vendors), reduce costs, and standardize wherever possible.

In facilitating the POC, LFIT will not be modifying any existing Jenkins pipelines or configurations. However, to effectively implement new workflows, we will require administrative access to view current configurations and to add additional configurations, variables, and secrets as necessary.

Thank you,
Vanessa Valderrama
LF Release Engineering

commented

Thanks for the clarifications @vvalderrv!
Over&reliance on a single vendor is something that always makes me a bit nervous although I appreciate that GitHub is likely a fast lower risk than with many others.

commented

I don't think this is feasible due to nodejs-private and the security release flow, and I fear we would end up with two CIs instead of one, almost unable to decommission the "old" Jenkins.

commented

With a few people commeting in terms of sharing concerns over the ROI/feasiblity of this, I'll add to my comment in #3651 (comment).

I'd much prefer any investment of time/$ from the Sovereign tech fund be focussed on immediate issues like improving the serving of downloads as we still see notifications from cloudflare about swapping back and forth between the two existing servers when the load gets high.