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

build: check against latest 12.x and 14.x #1313

Merged
merged 7 commits into from
Jul 20, 2020

Conversation

michaelfig
Copy link
Member

@michaelfig michaelfig commented Jul 19, 2020

This change has dapp-encouragement tested against the latest Node.js in the 12.x and 14.x lineage.

Also, reenable Yarn and Go caches.

@michaelfig michaelfig added the tooling repo-wide infrastructure label Jul 19, 2020
@michaelfig michaelfig requested a review from katelynsills July 19, 2020 23:21
@michaelfig michaelfig self-assigned this Jul 19, 2020
@michaelfig michaelfig force-pushed the mfig/test-latest-and-last-node branch from ff5292a to 3e6e054 Compare July 19, 2020 23:22
@michaelfig michaelfig requested a review from warner July 20, 2020 00:00
Copy link
Member

@warner warner left a comment

Choose a reason for hiding this comment

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

Sounds good to me, although I'm a tiny bit nervous about allowing CI to float. Our docs will say "requires node 12.16.1 or higher", or something, but we'll only be testing against 12.18.52, or something. If one of us starts depending upon something in the latest 12.x, but the others (or downstream users) haven't updated their Node in a while, CI won't catch it.

OTOH, if something in the latest 12.x changes and stops working with our tree, this kind of CI would catch it, and would catch it more reliably than hoping one of us randomly upgrades and notices. So it's a bit of a double-edged sword. If cycles were free, we could test against both some fixed minimum (which would be what our docs would doc as our minimum supported Node), and the latest 12.x, and hope the whole range in between is basically covered by testing the two endpoints.

But testing both seems like overkill, and if we're only testing one, I'm ok with either.

@michaelfig
Copy link
Member Author

If cycles were free, we could test against both some fixed minimum (which would be what our docs would doc as our minimum supported Node), and the latest 12.x, and hope the whole range in between is basically covered by testing the two endpoints.

Cycles virtually are free, because all the branches of a testing matrix are executed in parallel. So, I'll make that change.

But testing both seems like overkill, and if we're only testing one, I'm ok with either.

"Overkill" was my former middle name. 😉 Let's do both for the test-all-packages job, but leave the rest as 12.x, if that works for you.

@michaelfig michaelfig merged commit 2c506a2 into master Jul 20, 2020
@michaelfig michaelfig deleted the mfig/test-latest-and-last-node branch July 20, 2020 17:30
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
tooling repo-wide infrastructure
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants