-
Notifications
You must be signed in to change notification settings - Fork 13
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 separate checkout info block to buildscripts. #3545
Conversation
09f2396
to
6430b81
Compare
return false, errs.Wrap(err, "Unable to clone other buildscript") | ||
} | ||
|
||
// Do not compare project URLs. |
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.
If we compare URLs (which include commit IDs), we'll more often than not get false "your buildscript has changes, please commit" errors. Just compare the build expression and at time bits of the build script.
🎵 Churn baby churn 🎵 |
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.
Minimal churn!
if url, err := projectURL(proj, commitId.String()); err == nil { | ||
script.SetProject(url) | ||
} else { | ||
return errs.Wrap(err, "Unable to set project") | ||
} |
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.
You should be able to use project.URL()
here.
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, I cannot because the projecter has the old URL (with the old commit ID) from before a mutation. localcommit.Set() updates the URL on disk, but the primed project was not reloaded/reset/whatever, so its URL remains the same as it was originally.
I don't really see the point in changing this because when we replace project files with build scripts, we'll have to do something like constructing this URL again. I thought the point of this runbit was to know as little about projects as possible.
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 point. I don't like how opinionated the current solution is wrt the formatting of the URL though. I guess what this is touching on is that we probably need some central mechanic for project URLs. Still, to avoid further churn I think for this story we can maybe have a middle ground; like use project.URL()
and only splice in the commitID. So you'd avoid having any opinion on the URL beyond the commitID parameter.
internal/runbits/buildscript/file.go
Outdated
url, err := projectURL(proj, commitID.String()) | ||
if err != nil { | ||
return errs.Wrap(err, "Could not construct project URL") | ||
} |
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.
Same as above; use project.URL()
.
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.
Same as above.
"github.com/brunoga/deep" | ||
) | ||
|
||
// Tagged fields will be filled in by Participle. | ||
type rawBuildScript struct { | ||
Info *string `parser:"(RawString @RawString RawString)?"` |
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 think we should separate this from the parser entirely. Because we want to be able to access project info even if the buildscript itself has parsing issues.
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.
That sounds like a task for another day when we replace project files with build scripts, because right now, callers of buildscript.Unmarshal()
expect either a full, populated build script, or an error explaining why it didn't get one. We would have to refactor all callers to handle receiving a build script with only checkout info, or a fully populated one. Even still, I don't think they could do anything meaningful with a script that only has checkout info. (When we replace project files with build scripts, I can see us having the primer or some really early function make use of this to set things up, but then perhaps if that's the only use, it should be in a separate function from buildscript.Unmarshal()
, which can keep its existing behavior.)
Regardless, I feel like this is a rabbit hole and we shouldn't prescribe something that's not currently needed since we don't know the future requirements yet.
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.
Ok, that's fair. We'll leave it for when we get rid of the project URL in activestate.yaml.
if url, err := projectURL(proj, commitId.String()); err == nil { | ||
script.SetProject(url) | ||
} else { | ||
return errs.Wrap(err, "Unable to set project") | ||
} |
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 point. I don't like how opinionated the current solution is wrt the formatting of the URL though. I guess what this is touching on is that we probably need some central mechanic for project URLs. Still, to avoid further churn I think for this story we can maybe have a middle ground; like use project.URL()
and only splice in the commitID. So you'd avoid having any opinion on the URL beyond the commitID parameter.
"github.com/brunoga/deep" | ||
) | ||
|
||
// Tagged fields will be filled in by Participle. | ||
type rawBuildScript struct { | ||
Info *string `parser:"(RawString @RawString RawString)?"` |
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.
Ok, that's fair. We'll leave it for when we get rid of the project URL in activestate.yaml.
Also, ensure an updated build script with commit ID is always written.
state install
, etc.).