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

refactor redundant code into a function #339

Merged
merged 3 commits into from
Apr 10, 2023

Conversation

nitram509
Copy link
Contributor

What does this change

As discussed in PR #337 , this is the refactoring to consolidate the code for preparing command execution.

What issue does it fix

n/a

Notes for the reviewer

None.

Checklist

  • [/] Made sure the PR follows the CONTRIBUTING.md guidelines
  • [/] Tests if something new is added

"os/exec"
)

func prepareScriptCommand(ctx context.Context, repo scm.Repository, workDir string, scriptPath string, arguments []string, dryRun bool) (cmd *exec.Cmd) {
Copy link
Owner

Choose a reason for hiding this comment

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

At first, I thought we were able to reuse even more logic, but looking at it, it seems to not be the case.

Looking at the broken-out logic now, a lot of parts are just passed to the exec command without any logic, or extra config, which I don't think justifies the generalization. What I think could be useful to share is the setting of the environment variables that should be the same between run/print (REPOSITORY + the os environment).

func scriptEnv(repo scm.Repository) []string

Thoughts?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Keeping the env vars identical is definitely a great idea - I thought the same.
About the generalization ... yes, it's just minor, I agree.
Still, I would argue it's a good idea since it also gives a hint that 'print' and 'run' have much in common.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Overall I would argue, the broken-out logic might not be the strongest candidate for applying the DRY principle, but still, it helps to navigate/to remind that 'print' and 'run' have should have something in common.

PS: since run and print have different types, I was not able to use the same receiver, which would have simplified the parameter lists. I thought, it might be an idea to use type inheritance (see https://www.geeksforgeeks.org/inheritance-in-golang/), so that the print's and the run's receiver object would share e.g. the script path and the arguments.
That might lead to other shared functions as well (potentially).
Did you have tried that already, by any chance?

Copy link
Owner

Choose a reason for hiding this comment

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

I have not tried to break the logic into a shared struct-receiver. But that could potentially work. I would also be fine with this implementation, but the changes that would be needed are:

  • Let each parameter be on a newline to make it easier to read.
  • Remove if dryRun { from this function, it can be exclusively in run.go

@nitram509
Copy link
Contributor Author

changes are implemented, as proposed.

@lindell lindell merged commit b250c9b into lindell:master Apr 10, 2023
@lindell
Copy link
Owner

lindell commented Apr 10, 2023

Thanks for the contribution :)

@github-actions
Copy link
Contributor

github-actions bot commented May 2, 2023

Included in release v0.47.0 🎉

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants