-
Notifications
You must be signed in to change notification settings - Fork 56
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
Add support for dependentProjects in devfiles #1205
Conversation
Signed-off-by: Angel Misevski <[email protected]>
/retest |
Codecov ReportAttention:
Additional details and impacted files@@ Coverage Diff @@
## main #1205 +/- ##
==========================================
- Coverage 52.89% 52.75% -0.14%
==========================================
Files 84 84
Lines 7595 7616 +21
==========================================
+ Hits 4017 4018 +1
- Misses 3291 3309 +18
- Partials 287 289 +2 ☔ View full report in Codecov by Sentry. |
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.
Some minor comments below.
Also, the devfile API does not specify if it's valid to have a dependentProject but no regular projects.
I think it's outside the scope of DWO to do this validation, but it might make sense to make a bug about this for the devfile API's validation - not that this is a big deal IMO; I don't anticipate users to make devfiles with only dependentProjects and no regular projects.
pkg/library/projects/clone.go
Outdated
|
||
for idx, project := range workspace.DependentProjects { | ||
projectNames[project.Name] = append(projectNames[project.Name], "dependentProjects") | ||
clonePath := GetClonePath(&workspace.Projects[idx]) |
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.
This should be clonePath := GetClonePath(&project)
, and optionally you could get rid of idx
for both loops:
for _, project := range workspace.Projects {
projectNames[project.Name] = append(projectNames[project.Name], "projects")
clonePath := GetClonePath(&project)
clonePaths[clonePath] = append(clonePaths[clonePath], fmt.Sprintf("project %s", project.Name))
}
for _, project := range workspace.DependentProjects {
projectNames[project.Name] = append(projectNames[project.Name], "dependentProjects")
clonePath := GetClonePath(&project)
clonePaths[clonePath] = append(clonePaths[clonePath], fmt.Sprintf("dependentProject %s", project.Name))
}
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 use of idx
here is because we're taking the reference of the project. Some linters will complain about implicit memory aliasing here (since &project
is the same address every loop iteration). See e.g. the discussion here.
Doesn't impact us here since GetClonePath is just reading fields, but I'd still rather avoid a future false positive. This is something that's going to be fixed in Go 1.22
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.
Thank you for the explaining the context behind that pattern & glad to see it'll be fixed in the future :)
I should have been a bit more explicit, though: there's a subtle typo/bug. We're iterating over workspace.DependentProjects
but accessing &workspace.Projects[idx]
instead of &workspace.DependentProjects[idx]
. This causes validation to fail.
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.
Ahhh makes sense; thank you!
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.
No problem :)
I saw you force pushed some more commits, but this line still seems to use &workspace.Projects[idx]
instead of &workspace.DependentProjects[idx]
Given the purpose of dependentProjects, it's safe to assume such a devfile is valid. Most in-repo devfiles are assumed to not have a project included, since it's inferred from the containing repository. |
1eef996
to
5299844
Compare
Add verification step when starting workspace to make sure that no two projects (/dependentProjects/starterProjects) share the same name nor have the same clone path. Signed-off-by: Angel Misevski <[email protected]>
5299844
to
8662525
Compare
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, validation works as expected as well in my testing 👍
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: amisevsk, AObuchow The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
What does this PR do?
Adds support for dependentProjects as part of a DevWorkspace. As part of this, this PR also adds an additional validation step, to ensure no two projects:
What issues does this PR fix or reference?
Closes #1204
Is it tested? How?
Note: testing this PR requires running
make install
from the PR changes to ensure the updated DevWorkspace CRDs are installed.Can be tested via the following devfile:
This workspace should clone five projects:
To verify the validation steps, project names/clonePaths can be changed.
PR Checklist
/test v8-devworkspace-operator-e2e, v8-che-happy-path
to trigger)v8-devworkspace-operator-e2e
: DevWorkspace e2e testv8-che-happy-path
: Happy path for verification integration with Che