Skip to content

Restore backup assemblies when sigkill #383

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

Merged
merged 1 commit into from
May 2, 2019

Conversation

ViktorHofer
Copy link
Contributor

With sigkill or other execution interruptions the instrumented assemblies will remain in the output directory and the file backups won't be restored. Adding a cache to restore the backups in such cases.

cc @MarcoRossignoli @tonerdo

@MarcoRossignoli MarcoRossignoli requested a review from tonerdo April 25, 2019 16:31
@MarcoRossignoli
Copy link
Collaborator

MarcoRossignoli commented Apr 25, 2019

@ViktorHofer let me understand better the case...if the "test process" is "interrupted" for some reason why recover?I mean if it's stopped will be eventually replaced by new build/test, isn't it?

@ViktorHofer
Copy link
Contributor Author

If you want to "safely" instrument assemblies - means the output should be exactly the same as before - a sigkill could cause big troubles here. We are hitting this in corefx whenever a coverage measurement takes too long and the user kills the process. We don't rebuild all the assemblies that we use during the measurement, i.e. CoreLib.

But this isn't tied to corefx at all. Since the --include-directory option was added, additional assembly directories can be specified. Usually those additional inputs aren't rebuilt and should not get into a dirty state.

Copy link
Collaborator

@MarcoRossignoli MarcoRossignoli left a comment

Choose a reason for hiding this comment

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

LGTM, unrelated comments on statics.

@MarcoRossignoli
Copy link
Collaborator

MarcoRossignoli commented Apr 26, 2019

@tonerdo CI fail with some test on cecil tests...is it never happened before?It fails also on my local in Release config.

@tonerdo
Copy link
Collaborator

tonerdo commented Apr 29, 2019

@MarcoRossignoli taking a look now

@ViktorHofer
Copy link
Contributor Author

ViktorHofer commented May 2, 2019

Is this ready to be merged?

@MarcoRossignoli
Copy link
Collaborator

MarcoRossignoli commented May 2, 2019

@ViktorHofer in future we'll remove that static #387 for now if it's a blocking issue LGTM cc: @tonerdo

@ViktorHofer
Copy link
Contributor Author

Yeah let's merge this first and ideally publish a new package first and afterwards do the refactoring.

@tonerdo tonerdo merged commit 53fbc49 into coverlet-coverage:master May 2, 2019
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.

3 participants