-
Notifications
You must be signed in to change notification settings - Fork 211
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
fix: fix git dependencies comparison on bootstrap #659
base: main
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you add a very simple test that verifies this, so that we don't get a regression later?
Sure, but it will take a little longer, as I'm not very acquainted with this repository's tests. |
Super! You've probably already found it, but if not, you might be able to get some inspiration from the existing bootstrap tests (where the new test should live too): |
Hey, @spydon. Do you have any idea on how can I test git cloning with the tests suit? For For git, however, we have nothing. I don't fell like it would be advisable to test with a real repository, so I think we should fake this process, but I am not aware how we could do it. Currently, I'm using this fake object for a git reference: final pkg = await createProject(
workspaceDir,
const PubSpec(
name: 'package',
dependencies: {
'git': GitReference(
'url',
'reference',
'path',
),
},
),
); However, as I'm not faking the git repository, melos test tries to clone from bare repository |
Hey again @mateusfccp!
Can't you do the same, but with a temporary local git repository? You should be able to use a git file path url (not a path dependency) to that temporary repository. |
I actually didn't know we could do something like this. It worked! I'm not sure if this is the most straightforward way to test this, but it works. Let me know if I can improve it somehow. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Lgtm, I think that test is good enough
It seems it failed on Windows and Linux, although it worked on Mac (the platform I'm working with). The error seems to indicate that the path is not a git repository, even tho I initialized it and made a commit. Unfortunately, I have no Linux or Window machine to debug the problem here... Do you have any idea what it could be? |
Signed-off-by: Mateus Felipe C. C. Pinto <[email protected]>
Signed-off-by: Mateus Felipe C. C. Pinto <[email protected]>
Signed-off-by: Mateus Felipe C. C. Pinto <[email protected]>
Sorry, I though I replied after reading it a few days ago! |
No, not really. I just rebased the PR... I searched for potential differences in git between platforms, but didn't find anything relevant, so still in the darkness. Edit: Maybe it's some difference in the CI environment? Could be permission related? |
@mateusfccp just realized you probably can't see the CI logs?
|
Yes, I can see them. Like I said, this error seems to mean that the git repository was not created correctly or the commit. I did pass through this error while writing the test, because at first I was only creating the git repository with This is why I think either the git initialization or the commit is failing in some weird way. |
|
||
await io.Process.run( | ||
'git', | ||
['add', '-A'], |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Empty directories won't be added to git, maybe create an empty file in both of the directories first?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The directory, supposedly, is not empty, as we created two projects within it with createProject
.
If this was not the case, the test would not pass in my local machine either.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah right, I read createDirectory
and not createProject
when I read it this morning. 😅
The test passes locally for me too (linux), so permissions does sound like a good guess, but it doesn't look like it from the error message in the pipeline, if it doesn't fail silently earlier.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am going to try to reproduce the problem by using a container locally and running the same images. Maybe I can debug this way.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good idea, I re-ran the failing test with GitHub debug printing, but it didn't give anything
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@mateusfccp did you manage to find anything causing it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hello, @spydon.
Sorry for the delay. I actually didn't get to reproduce the environment on my local machine. I tried to do it with act
, but with no success.
@@ -363,7 +371,13 @@ mixin _BootstrapMixin on _CleanMixin { | |||
// dependencies that have a different version specified in the workspace. | |||
final dependenciesToUpdate = workspaceDependencies.entries.where((entry) { | |||
if (!packageDependencies.containsKey(entry.key)) return false; | |||
if (packageDependencies[entry.key] == entry.value) return false; | |||
// TODO: We may want to replace the `pubspec` dependency with something |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is replaced with pubspec_parse now
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this PR obsolete or does the bug still exist? I am updating it, but I realized that the package has changed and I am not sure if it solves the problem by itself.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure. Can you try running main
?
Description
Fixes comparison check of
GitReference
by also comparing thepath
.Fixes #658.
Type of Change
feat
-- New feature (non-breaking change which adds functionality)fix
-- Bug fix (non-breaking change which fixes an issue)!
-- Breaking change (fix or feature that would cause existing functionality to change)refactor
-- Code refactorci
-- Build configuration changedocs
-- Documentationchore
-- Chore