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

Add separate checkout info block to buildscripts. #3545

Merged
merged 6 commits into from
Oct 18, 2024

Conversation

mitchell-as
Copy link
Contributor

@mitchell-as mitchell-as commented Oct 17, 2024

StoryDX-3024 Non-versioned buildscript information is clearly denoted

  • Use triple-backticks to separate checkout info from buildscript. Using triple-quotes will require a new parser and/or lexer. Since we're experimenting, let's use what we have.
  • Internal change in the raw buildscript format to not store strings with quotes. (Unmarshaling strips quotes, and marshaling adds them back.)
  • Users are shown a warning if they attempt to use an outdate build script (state install, etc.).

return false, errs.Wrap(err, "Unable to clone other buildscript")
}

// Do not compare project URLs.
Copy link
Contributor Author

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.

@mitchell-as mitchell-as reopened this Oct 17, 2024
@mitchell-as
Copy link
Contributor Author

🎵 Churn baby churn 🎵

@mitchell-as mitchell-as requested a review from Naatan October 17, 2024 19:16
@mitchell-as mitchell-as marked this pull request as ready for review October 17, 2024 19:16
Copy link
Member

@Naatan Naatan left a comment

Choose a reason for hiding this comment

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

Minimal churn!

Comment on lines +68 to +72
if url, err := projectURL(proj, commitId.String()); err == nil {
script.SetProject(url)
} else {
return errs.Wrap(err, "Unable to set project")
}
Copy link
Member

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.

Copy link
Contributor Author

@mitchell-as mitchell-as Oct 18, 2024

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.

Copy link
Member

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.

Comment on lines 126 to 129
url, err := projectURL(proj, commitID.String())
if err != nil {
return errs.Wrap(err, "Could not construct project URL")
}
Copy link
Member

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().

Copy link
Contributor Author

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)?"`
Copy link
Member

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.

Copy link
Contributor Author

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.

Copy link
Member

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.

@mitchell-as mitchell-as requested a review from Naatan October 18, 2024 18:26
Comment on lines +68 to +72
if url, err := projectURL(proj, commitId.String()); err == nil {
script.SetProject(url)
} else {
return errs.Wrap(err, "Unable to set project")
}
Copy link
Member

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)?"`
Copy link
Member

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.
@Naatan
Copy link
Member

Naatan commented Oct 18, 2024

image
👍

@mitchell-as mitchell-as merged commit 4feb03e into version/0-47-0-RC1 Oct 18, 2024
16 of 21 checks passed
@mitchell-as mitchell-as deleted the mitchell/dx-3024-4 branch October 18, 2024 21:27
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants