feat: add after build command option#77
Conversation
9a9bd7b to
20d456d
Compare
|
Delete the workspace file. Add a test? |
20d456d to
3d1b424
Compare
|
Thanks for the review, I updated the PR with your inputs |
|
/gemini review |
There was a problem hiding this comment.
Code Review
This pull request introduces an afterBuildCommand option, allowing a command to be run after the build process. The implementation is sound and is accompanied by a comprehensive set of integration tests that cover various success and failure scenarios. I've provided a couple of suggestions to address code duplication in both the implementation and the tests to enhance maintainability. Overall, this is a valuable addition.
| if (afterBuildCommand != null && afterBuildCommand.isNotEmpty) { | ||
| var executable = afterBuildCommand.first; | ||
| if (executable == 'DART') { | ||
| executable = dartPath; | ||
| } | ||
|
|
||
| final arguments = afterBuildCommand.skip(1).toList(); | ||
|
|
||
| await _runProc(executable, arguments, workingDir); | ||
| } |
There was a problem hiding this comment.
The logic to parse the command, resolve the DART placeholder, and prepare arguments is duplicated from lines 46-52 where the main command is processed. To improve maintainability and avoid redundancy, consider extracting this logic into a private helper function. This function could take a List<String> command and either run the process directly or return the prepared executable and arguments.
| group('afterBuildCommand when a file changes', () { | ||
| const pubspecLockFileName = 'pubspec.lock'; | ||
|
|
||
| setUp(() async { | ||
| await gitDir.runCommand(['add', pubspecLockFileName]); | ||
| await gitDir.runCommand(['commit', '-am', 'commit pubspec']); | ||
| }); | ||
|
|
||
| test('should fail if afterBuildCommand produces git changes', () async { | ||
| final afterBuildCommand = [ | ||
| 'sh', | ||
| '-c', | ||
| 'echo "new content just for this test" > $pubspecLockFileName', | ||
| ]; | ||
|
|
||
| await expectLater( | ||
| expectBuildCleanImpl(d.sandbox, afterBuildCommand: afterBuildCommand), | ||
| throwsATestFailure, | ||
| ); | ||
| }); | ||
|
|
||
| test( | ||
| 'should succeed if afterBuildCommand produces git changes which are then ' | ||
| 'ignored by gitDiffPathArguments', | ||
| () async { | ||
| final afterBuildCommand = [ | ||
| 'sh', | ||
| '-c', | ||
| 'echo "new content just for this test" > $pubspecLockFileName', | ||
| ]; | ||
|
|
||
| await expectBuildCleanImpl( | ||
| d.sandbox, | ||
| afterBuildCommand: afterBuildCommand, | ||
| gitDiffPathArguments: [':!$pubspecLockFileName'], | ||
| ); | ||
| }, | ||
| ); | ||
| }); |
There was a problem hiding this comment.
The afterBuildCommand variable is defined in both tests within this group, leading to code duplication. To improve readability and maintainability, you can define it once at the group level and reuse it in both tests.
group('afterBuildCommand when a file changes', () {
const pubspecLockFileName = 'pubspec.lock';
final afterBuildCommand = [
'sh',
'-c',
'echo "new content just for this test" > $pubspecLockFileName',
];
setUp(() async {
await gitDir.runCommand(['add', pubspecLockFileName]);
await gitDir.runCommand(['commit', '-am', 'commit pubspec']);
});
test('should fail if afterBuildCommand produces git changes', () async {
await expectLater(
expectBuildCleanImpl(d.sandbox, afterBuildCommand: afterBuildCommand),
throwsATestFailure,
);
});
test(
'should succeed if afterBuildCommand produces git changes which are then '
'ignored by gitDiffPathArguments',
() async {
await expectBuildCleanImpl(
d.sandbox,
afterBuildCommand: afterBuildCommand,
gitDiffPathArguments: [':!$pubspecLockFileName'],
);
},
);
});
Introduced an optional command that will be executed after the build_runner execution