Skip to content

chore: use lts node version in CI - #2259

Closed
SgtPooki wants to merge 20 commits into
mainfrom
chore/update-ci-node-version
Closed

SgtPooki wants to merge 20 commits into
mainfrom
chore/update-ci-node-version

Conversation

@SgtPooki

Copy link
Copy Markdown
Member

Updates all github workflows selections of node-version to be "lts/*"

@SgtPooki
SgtPooki requested a review from a team as a code owner September 12, 2024 21:42
@SgtPooki
SgtPooki changed the base branch from 2250-webui-spawning-helia-and-failing-to-establish-libp2p-webtransport-connections to main September 12, 2024 21:46
@SgtPooki
SgtPooki changed the base branch from main to 2250-webui-spawning-helia-and-failing-to-establish-libp2p-webtransport-connections September 12, 2024 21:46
Base automatically changed from 2250-webui-spawning-helia-and-failing-to-establish-libp2p-webtransport-connections to main September 13, 2024 19:41
An error occurred while trying to automatically change base from 2250-webui-spawning-helia-and-failing-to-establish-libp2p-webtransport-connections to main September 13, 2024 19:41

@SgtPooki SgtPooki left a comment

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

self review

@lidel lidel left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

building with 20 lgtm, but it fails to build for me with v22.4.1, so the CI will break when 24 becomes LTS and someone will have to search for last working version and hardcode it again 😿

is lts/* useful in CI of rarely-maintained apps? i remember the same breackage occuring 12→14→16→18 (nearly every time a change of LTS image broke CI in one of our legacy JS apps)

maybe hardcode to 20.x to avoid headache? (not feeling strongly, i'd just rather not deal with problem once LTS breaks again)

@SgtPooki

Copy link
Copy Markdown
Member Author

is lts/* useful in CI of rarely-maintained apps? i remember the same breackage occuring 12→14→16→18 (nearly every time a change of LTS image broke CI in one of our legacy JS apps)

most likely not, but we probably want to see a failure when it occurs right?

maybe hardcode to 20.x to avoid headache? (not feeling strongly, i'd just rather not deal with problem once LTS breaks again)

That is good with me, but we should probably target 22 now since it's going active very soon

image

@SgtPooki

Copy link
Copy Markdown
Member Author

I think once I get ipfs/ipld-explorer-components#448 done, we will be closer to updating everything here.

SgtPooki added a commit that referenced this pull request Nov 1, 2024
SgtPooki added a commit that referenced this pull request Nov 7, 2024
* feat: use latest ipld-explorer-components

* fix: unit tests pass

* fix: e2e tests work

* fix: update ipld-explorer-components patch

* fix: storybook ci tests pass

* chore: fix dep-check

* feat: use latest ipld-explorer-components

* feat: use latest ipld-explorer-components

* feat: resolve button types issue

* chore: fix depcheck

* test: fix storybook tests

* chore: attempt to fix fleek deploy

* test: stop using react-rewired-esm for unit tests

* test: use kubo standard ports for e2e tests

* chore: use ipld-explorer-components@8.1.0

* chore: use node lts version

replaces #2259
@SgtPooki

SgtPooki commented Nov 7, 2024

Copy link
Copy Markdown
Member Author

done in #2283

@SgtPooki SgtPooki closed this Nov 7, 2024
ipfs-gui-bot pushed a commit that referenced this pull request Nov 7, 2024
## [4.4.0](v4.3.3...v4.4.0) (2024-11-07)

 CID `bafybeibkirkltohusogcco46jcw7khtgjf5nwphuvufjssr5pvhsuol5uy`

 ---

### Features

* use ipld-explorer-components@8.1.0 ([#2283](#2283)) ([437b8fe](437b8fe)), closes [#2259](#2259)

### Bug Fixes

* normalize catch-all listeners to loopback ([#2287](#2287)) ([edf14c6](edf14c6)), closes [#1821](#1821)
* remove iltorb dep, build for node v22.9.0 ([#2273](#2273)) ([9ba4559](9ba4559))

### Trivial Changes

* move enum.js to lib folder ([#2285](#2285)) ([682de0b](682de0b))
* pull new translations ([#2279](#2279)) ([8205d12](8205d12))
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants