-
Notifications
You must be signed in to change notification settings - Fork 2.3k
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
WIP: Feature: creation of relocatable tarballs from installed packages #1013
Conversation
Add recursion and force-overwrite to create-tarball.
Fix dependency recursion.
o Add lazy policy for install o Use Stage class for download o Add meta-data o Improve logging
…ation of some code
@mathstuf I added the gpg2 signing and verification as options. |
@mathstuf |
Hmm, there should probably be a As for signing, I think it shouldn't be an option. Packages should always be signed when created and there should be a (hidden?) option to skip verification of packages when installing them. |
Oh, that file is under |
I see that there is a keys directory in Should I put my public key in |
Does the buildcache command need an upload subcommand? We usually do that by hand or with and external script. |
Add gartung.key as trusted key.
…/spack/gpg and spack gpg init to add them as trusted keys.:
@mathstuf |
Yes, that directory should be relocatable (it's just a spack-specific |
except fs.FetchError: | ||
next | ||
if install: | ||
Gpg.trust(stage.save_filename) |
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 there should be a verification before this. Something like:
This package is signed by this key:
<key info>
Do you want to trust this key? [y/N] >
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.
Or this key was found on mirror <mirror name>
.
@gartung it looks to me like codecov is reporting coverage properly. I find the diff view in codecov is the easiest to interpret. I would certainly like to see more tests for this feature, with the caveat that I have not yet reviewed it sufficiently to have any understanding of how difficult it will be to create those tests. |
Another thing to clarify about the Codecov values is that they are the comparison of this branch with the current develop, not with develop at the time this PR branched off. If coverage has increased in develop since you branched off, it will show up in the diff here. So if you rebase on the tip of develop, you'll get a better idea at how the global coverage is being affected. With that said, the |
So the red in the diff view is code that is not covered by a test? |
Well, the red in the "Files changed" view is lines that were removed, but if you install the Codecov extension, the red lines will be lines not covered by unit tests. |
The muted red/green background in the "diff" view is the changes to the code, but the bright red/green bar on the left is covered/not covered lines of code |
I am going to resubmit once I get this code coverage thing figured out. |
This extends #445 which allows the creation of binary tarballs from installed packages and the installation of those tarballs on other machine with the appropriate rewriting of rpaths with patchelf on linux or install_name_tool on macos.