-
Notifications
You must be signed in to change notification settings - Fork 25
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
added additional rpm handling #38
Conversation
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.
Looks good to me. There are several suggestions that we'd need to take care of but nothing major in those - good job!
One thing to mention is that there's no documentation around the /rpms
directory in the README and you might also want to sync with @ipetrov117 since he's also looking into how RPMs will be handled.
pkg/build/rpm.go
Outdated
if rpmSourceDir == "" { | ||
return nil | ||
} | ||
rpmDestDir := b.combustionDir |
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 am not sure what use we get from moving the b.combustionDir
property to rpmDestDir
and using it in copyRPMs
. Can't we just use b.combustionDir
directly as a parameter to the copyRPMs
function? That way we will save up one more line of code that we have to write without making the existing code too complex.
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 mainly added this so that it's clear that there was a variable that held where the rpms should go in the end, but like you said we can save that line by omitting it, will update 👍
The doc around the Regarding the RPM handling, the suggested changes here offer a good base line from where we could continue with the air-gapped RPM handling. Granted, some files would have to be changed (the |
One more thing that got me wondering looking at the script execution comment that @atanasdinov made. Does it make sense for us to start naming our scripts with That said, I still do not have the full picture so I might be wrong here. @atanasdinov @jdob @dbw7 wdyt? |
You're completely correct. My comment was indeed to point out that the introduced What we need to consider is how the structure of the |
In this case, the XX_ was intentionally used because of the alphabetical sorting. We're gonna need the RPMs in place before the elemental register stuff kicks in. But you're right that we need to go back through and evaluate all of them for this sort of thing. Danny and I were talking yesterday, I'm thinking something like 0X-5X are what we use, opening up 6X-8X for users (this will need to be documented, of course). That way the user has some room to play with their own custom scripts while also having hooks if they need to fit into a specific point in what we do. |
26f37d2
to
ed08751
Compare
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.
A couple of issues with the tests. Happy to approve after those are resolved, linter issues are fixed (using camelCase for variable names) and the /testdata/rpms
dir is dropped.
let me know if this is what you were meaning, I could have misinterpreted when it came to the rpm path part
e363c73
to
4e9e3a7
Compare
Just to ensure that we're all on the same page, I just pushed this (#38) as an example for how a local repo could be generated; the repo here is important as it can be simply added from Combustion:
I know that @ipetrov117 is working on making that script more consumable via EIB but it's important that we're considering user-provided RPM's, along with a list of package names that can be pulled from SLE repo's as well as user-provided repo's. Therefore we need to think about this PR in the context of generating the entire repo, and installing an identified list of packages, rather than just rpm's placed into the |
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.
A final touch would be to reduce the duplicate setup code in tests with something similar to the following:
func setupRPMSourceDir(t *testing.T) (string, func()) {
tmpDir, err := os.MkdirTemp("", "eib-RPM-")
require.NoError(t, err)
rpmSourceDir := filepath.Join(tmpDir, "rpms")
err = os.Mkdir(rpmSourceDir, 0o755)
require.NoError(t, err)
file1Path := filepath.Join(rpmSourceDir, "rpm1.rpm")
file1, err := os.Create(file1Path)
require.NoError(t, err)
file2Path := filepath.Join(rpmSourceDir, "rpm2.rpm")
file2, err := os.Create(file2Path)
require.NoError(t, err)
return tmpDir, func() {
assert.NoError(t, file1.Close())
assert.NoError(t, file2.Close())
assert.NoError(t, os.RemoveAll(tmpDir))
}
}
You can then use this in the various different test functions with:
rpmSourceDir, teardown := setupRPMSourceDir(t)
defer teardown()
Now this is awesome, thank you for writing this. I wasn't sure if it was a normal thing to make helper functions for tests so I avoided it, but I'm glad to see it's possible. Extra thanks as this allowed me to clean up the code significantly. |
finishing touch, processRPMs needs to come before generateCombustionScript so that the rpm script is registered
Very open to feedback on this