Analyzing the output of ECG #26
Labels
No Label
Compat/Breaking
Kind/Bug
Kind/Documentation
Kind/Enhancement
Kind/Feature
Kind/Security
Kind/Testing
Kind/Thinking
Priority
Critical
Priority
High
Priority
Low
Priority
Medium
Reviewed
Confirmed
Reviewed
Duplicate
Reviewed
Invalid
Reviewed
Won't Fix
Status
Abandoned
Status
Blocked
Status
Need More Info
No Milestone
No project
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: GuilloteauQ/study-docker-repro-longevity#26
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
In order to study the reproducibility of the Dockerfiles, we need a script that can analyze the outputs of ECG to extract interesting data, and another script that plots the extracted data.
Some ideas of what we could plot:
All of these plots can be done both on the outputs of a single execution, or on outputs generated over time after multiple executions (except for plots that measure change).
Regarding the build status analysis: it was decided not to log the build status of Dockerfiles that build successfully, but it makes analysis harder: how to determine the number of Dockerfiles that build successfully if this success hasn't been logged?
Shouldn't we log that when build was successful?
i would say that the ones that built successfully are the ones not present in the
blacklist
My question is rather how to count them if they are not in the file?
number of artifacts in the
artifacts/
folder minus the one in the blacklist?Sure, but wouldn't it be simpler to just put them on the build status file? Your solution would require another argument for the analysis script which is the artifact folder, and then the script should count them and subtract the amount of artifact that failed... It looks a bit cumbersome for nothing to me...
So we can log the successful build status, we just need to generate the blacklist correctly afterward.
for now the blacklist is just a concatenation of all the build status files.
If you feel like it helps the analysis to have the success status, go for it 🙂
Oh, I see... It would complicate the generation of the blacklist?
not much i would say.
we would just need to filter out the successful builds
Okay, then I'm going to do that on the Snakefile, it looks like it would be simpler for the analysis indeed.
We can summarize the output analysis as follow:
The analysis part should be done now, closing this issue.