-
Notifications
You must be signed in to change notification settings - Fork 5
Allow running in place on an existing checkout #53
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
Conversation
action.yml
Outdated
| description: "Actions to correct" | ||
| required: false | ||
| default: ".github/workflows" | ||
| default: '[".github/workflows"]' |
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.
Hey @segiddins thank you for your contributio!
I'm not an expert here, but this looks like a breaking change, how would this impact existing users of the action?
cc @evankanderson
evankanderson
left a comment
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 like the idea. A couple requests:
- Rather than a true/false value, let's make the in-place enablement use a path, where the empty value uses the current behavior.
- It seems like the in-place behavior implicitly disables the PR path today. It feels like we should make those separate -- e.g. create the
githubClientif the token is present, and pass that in to the action whether it's working on a local checkout or remote. (Unless there's a good reason to make these arguments exclusive.)
action.yml
Outdated
| in_place: | ||
| description: "Update the files in place" | ||
| required: false | ||
| default: "false" |
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.
So, I agree that the existing action is a bit weird -- what would you think about making this be a directory path argument, where the default "" value means to do the existing fetch-from-github behavior? i.e.
| in_place: | |
| description: "Update the files in place" | |
| required: false | |
| default: "false" | |
| repo_root: | |
| description: "Operate on files in the specified filesystem location. If unspecified, check out files from the current repo." | |
| required: false | |
| default: "" |
main.go
Outdated
| var repo *git.Repository | ||
| var fs billy.Filesystem | ||
| var githubClient *github.Client | ||
| var token string |
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 looks like a bunch of these (particularly githubClient and token) don't get initialized on the "directory" path. Should we remove them?
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 tricky thing is they're used when creating the action.FrizbeeAction, so they need to be defined unconditionally
main.go
Outdated
| ActionsPath: os.Getenv("INPUT_ACTIONS"), | ||
| ActionsPaths: envToStrings("INPUT_ACTIONS"), |
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'd prefer to add a second argument which covers the multiple-paths option (which could be exclusive with the single argument), OR to change valToStrings to also interpret the input foo as equivalent to ["foo"]. (To be honest, I'd rather have had comma-delimited strings over JSON elsewhere, but that ship has sailed.)
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.
Thinking further, I converting foo to ["foo"] is dangerous, because we might end up with ["[\"foo\",\n]" depending on how strict the JSON parser is and how lazy the user is. Maybe add a second argument for multiple GitHub Actions directories?
pkg/action/action.go
Outdated
| ImagesReplacer *replacer.Replacer | ||
| BFS billy.Filesystem | ||
| Repo *git.Repository | ||
| bodyBuilder *strings.Builder |
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.
Removing bodyBuilder seems like a (nice) simple refactor which doesn't change behavior. I could approve that change real fast if it wasn't entangled in the behavior change around ActionsPaths changing contents.
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.
| @@ -1,4 +1,4 @@ | |||
| FROM golang:alpine3.19@sha256:0466223b8544fb7d4ff04748acc4d75a608234bf4e79563bff208d2060c0dd79 | |||
| FROM golang:1.23.1-alpine3.20@sha256:ac67716dd016429be8d4c2c53a248d7bcdf06d34127d3dc451bda6aa5a87bc06 | |||
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 we include this change in another PR? I think it's a good change.
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 @segiddins! I'm excited about this PR -- anything we can do to help you out in revisitng this? |
|
I'll try to circle back next week! |
850cb44 to
11c08b2
Compare
|
@evankanderson This should be ready for another look, along with the other two PRs! |
|
@segiddins hey, it looks like the linter is complaining about the cyclomatic complexity of the init function now. I'll leave it up to you if you want to reduce the complexity or just slap a |
Signed-off-by: Samuel Giddins <segiddins@segiddins.me>
Signed-off-by: Samuel Giddins <segiddins@segiddins.me>
…omatic complexity Signed-off-by: Samuel Giddins <segiddins@segiddins.me>
c162fda to
7080386
Compare
|
Let's see if this helps? |
Signed-off-by: Samuel Giddins <segiddins@segiddins.me>
jhrozek
left a comment
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 this looks good and the changes seem to be backwards-compatible
Ran into this when I was setting up rubygems/rubygems.org#5019 -- I want to just run frizbee on the current checkout, so it can run on every PR