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

Make CI green again #242

Closed
victorb opened this issue May 8, 2018 · 16 comments
Closed

Make CI green again #242

victorb opened this issue May 8, 2018 · 16 comments
Assignees
Labels
exp/novice Someone with a little familiarity can pick up P0 Critical: Tackled by core team ASAP

Comments

@victorb
Copy link
Member

victorb commented May 8, 2018

Currently, master has not had a passing build since 6 of April (https://ci.ipfs.team/job/IPFS/job/js-ipfsd-ctl/job/master/) and none of the PRs are having green builds right now.

Since js-ipfsd-ctl is a integral part in our development and testing, we have to make the tests pass as long as the code is correct. Having flaky tests is a deal breaker, as we start ignoring the test results.

I'm not sure why the builds are not passing, but we should stop adding new features or fixes until we can trust CI, as otherwise we cannot safely merge changes.

@dryajov
Copy link
Member

dryajov commented May 8, 2018

Agree. Now that most changes related to class-is have been bubbled, it should be green again. Looking into it now.

@dryajov
Copy link
Member

dryajov commented May 9, 2018

After investigating, in order to make CI green again, we need:

@victorb
Copy link
Member Author

victorb commented May 14, 2018

@dryajov seems we could already open a PR and manually override the node modules to at least see if makes it green, correct?

@dryajov
Copy link
Member

dryajov commented May 14, 2018

@victorbjelkholm We can, but that would still break for our users, wont it?

I think what we need is to release a hot fix js-ipfs with the locked js-ipfs-repo version to 0.20.0. The reason this is all broken now, is because we used ^ for 0.x.x versions, and broke semantic versioning in js-ipfs - this is now broken for everybody not just ipfsd-ctl. I think this is pretty bad, but fixing it just for the CI won't make this issue go away.

@dryajov
Copy link
Member

dryajov commented May 14, 2018

Ah, I take that back @victorbjelkholm - we only need to pin it down here, js-ipfs is fine as it is still on 0.18.x...

@dryajov
Copy link
Member

dryajov commented May 14, 2018

The ^ vs ~ issue still stands, as we're wrongly using ^ for ipfs-version here - https://github.com/ipfs/js-ipfsd-ctl/blob/master/package.json#L89, which forces it to pick up the latest, ipfs-repo version 0.21.0. We need to pin it to ~0.20.0.

@victorb
Copy link
Member Author

victorb commented May 14, 2018

@dryajov yeah, I just wanted to confirm that what we think would solve the issue, actually solves it (reproduce it externally so we can be 100% nothing more needs to get done).

Speaking about ^ vs ~, is there a reason we don't just specify the versions as-is, without any version ranges? Having dependencies automatically switch out from under you feels like a bad default. Way easier to just remember "no version ranges" than "Use ~ for everything below 1.0.0 and ^ for everything above 1.0.0" as well. We could also enforce this via CI if we'd wish (even the ~/^ rule could be enforced)

@dryajov
Copy link
Member

dryajov commented May 14, 2018

Yeah, I agree, but I would suggest we just use lock files, since thats what they were made for - it would make sense to just lock to a version had they not been introduced.

@victorb
Copy link
Member Author

victorb commented May 14, 2018

@dryajov lock files would be nice. Would be even nicer with lock files that works both for yarn (I know many of the devs that uses yarn (and me) + CI uses yarn) and npm (probably most people still using npm?), since they have different ones. Locking the version directly in package.json works for both though.

@dryajov
Copy link
Member

dryajov commented May 14, 2018

good point, forgot about incompatible lock files 😭

@vasco-santos vasco-santos added need/community-input Needs input from the wider community P0 Critical: Tackled by core team ASAP labels May 17, 2018
@daviddias daviddias added the status/ready Ready to be worked label May 30, 2018
@daviddias
Copy link
Member

@vasco-santos now that js-ipfs has been released, you can updates and get CI green again.

@daviddias daviddias added exp/novice Someone with a little familiarity can pick up and removed need/community-input Needs input from the wider community labels May 30, 2018
@vasco-santos
Copy link
Member

@diasdavid CircleCI is not green yet!

Last time it was green was in @dryajov PR. Dmitriy do you know what is wrong now?

@dryajov
Copy link
Member

dryajov commented May 31, 2018

The failures come from the version logic:

screen shot 2018-05-30 at 7 09 12 pm

screen shot 2018-05-30 at 7 08 48 pm

There is a bug in js-ipfs introduced with https://github.com/ipfs/js-ipfs-repo/pull/164/files#diff-1fdf421c05c1140f6d71444ea2b27638R216. Changing the error message broke version handling, which ignores uninitialized repos and sources the version directly from the package if no repo exists. Here is a fix ipfs/js-ipfs#1374.

@vasco-santos
Copy link
Member

Thanks for your analyzes @dryajov !

@alanshaw
Copy link
Member

alanshaw commented Jun 1, 2018

@vasco-santos
Copy link
Member

CI is green again!! 🙌
Thank you all

@ghost ghost removed the status/ready Ready to be worked label Jun 1, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
exp/novice Someone with a little familiarity can pick up P0 Critical: Tackled by core team ASAP
Projects
None yet
Development

No branches or pull requests

5 participants