foreman-develop-source-release 1918 failed

Infra & CI
1

foreman source release pipeline failed:

https://ci.theforeman.org/job/foreman-develop-source-release/1918/

2

@evgeni The failure is the same as katello nightly failure.

[2023-04-11T07:45:54.376Z] npm ERR! code ENOTSUP

[2023-04-11T07:45:54.376Z] npm ERR! notsup Unsupported engine for sass@1.61.0: wanted: {"node":">=14.0.0"} (current: {"node":"12.22.12","npm":"6.14.16"})

[2023-04-11T07:45:54.376Z] npm ERR! notsup Not compatible with your version of node/npm: sass@1.61.0

[2023-04-11T07:45:54.376Z] npm ERR! notsup Not compatible with your version of node/npm: sass@1.61.0

[2023-04-11T07:45:54.376Z] npm ERR! notsup Required: {"node":">=14.0.0"}

[2023-04-11T07:45:54.376Z] npm ERR! notsup Actual:   {"npm":"6.14.16","node":"12.22.12"}

We updated katello github CI to Node 14. Should we be doing the same for all our infra?
The other option is to pin Saas to pre-breaking change commit:

2 Likes
3

I think switching to NodeJS 14 is “better” (no idea how if at all that interferes with @MariaAga and @Shimon_Shtein plans to update the JS stack), but would require also updating the packaging side of things (which currently uses 12 too).

1 Like
4

in the devel scenario we enable the dnf module nodejs 14, dnf install npm, and everything just works (cool, so we just ship the devel scenario and call it a day, right??)

when you refer to “updating the packaging side of things” do you mean that some spec files will require updates, or are updates needed to the packaging infrastructure? how much effort do you estimate that involves?

5

For Debian, we currently configure the 12.x nodesource repo in

This would need changing to 14.x and ensuring all supported Foreman releases (3.5+) build with it (I think that’s the case, but still mentioning it here as we today have no way to configure this per-release)

For RPM, we’d need to reconfigure our module splitter to either not throw away nodejs 14 or change the config so that it uses a “split” repo (like we do for Ruby and Python these days, where each module is an own repo). I’ll defer to @ehelms, @pcreech and @Odilhao on how actually complicated this is.

6

I think we should pin the package in the short term, because we’ll need that for our stable releases. Unless we plan on updating Node in 3.5 & 3.6 as well.

I think that’s concerning, because we actually build and ship with Node 12 so it’s not really covering what we will use.

1 Like
7

From my current viewpoint it shouldn’t interfere. Basically as long as the underlying libraries do not limit node versions - purely from WP5 perspective there shouldn’t be a problem to use node 14.

8

We did pin sass instead: Fixes #36305 - Pin sass version to 1.60.z to avoid node 14 dependency · theforeman/foreman@a5feafd · GitHub

9

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.