Skip to content
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

LFIT Jenkins transition to GHA POC #3651

Open
vvalderrv opened this issue Mar 13, 2024 · 10 comments
Open

LFIT Jenkins transition to GHA POC #3651

vvalderrv opened this issue Mar 13, 2024 · 10 comments

Comments

@vvalderrv
Copy link

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: [email protected]

GitHub
username: lfreleng-github

Thank you,
Vanessa Valderrama
LF Release Engineering

@richardlau
Copy link
Member

@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.

@nschonni
Copy link
Member

Some old discussions around this #2247

@mhdawson
Copy link
Member

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.

@vvalderrv
Copy link
Author

@

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

@sxa
Copy link
Member

sxa commented Mar 14, 2024

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?

@UlisesGascon
Copy link
Member

@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.

@vvalderrv
Copy link
Author

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

@sxa
Copy link
Member

sxa commented Mar 19, 2024

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.

@mcollina
Copy link
Member

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.

@mhdawson
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

7 participants