Skip to content
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

Merged
merged 19 commits into from
Nov 17, 2023
Merged

Conversation

dbw7
Copy link
Contributor

@dbw7 dbw7 commented Nov 13, 2023

Very open to feedback on this

pkg/build/rpm.go Outdated Show resolved Hide resolved
pkg/build/rpm_test.go Outdated Show resolved Hide resolved
pkg/build/rpm_test.go Outdated Show resolved Hide resolved
pkg/build/rpm_test.go Outdated Show resolved Hide resolved
pkg/build/rpm_test.go Outdated Show resolved Hide resolved
pkg/build/rpm_test.go Outdated Show resolved Hide resolved
pkg/build/rpm_test.go Outdated Show resolved Hide resolved
pkg/build/scripts/rpms/10_rpm_install.sh.tpl Outdated Show resolved Hide resolved
pkg/build/rpm.go Outdated Show resolved Hide resolved
pkg/build/rpm.go Outdated Show resolved Hide resolved
@dbw7 dbw7 requested a review from jdob November 14, 2023 00:13
Copy link
Contributor

@atanasdinov atanasdinov left a 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 Show resolved Hide resolved
pkg/build/rpm.go Outdated Show resolved Hide resolved
pkg/build/rpm.go Outdated Show resolved Hide resolved
pkg/build/rpm.go Show resolved Hide resolved
pkg/build/rpm_test.go Outdated Show resolved Hide resolved
pkg/build/rpm_test.go Outdated Show resolved Hide resolved
pkg/build/rpm_test.go Outdated Show resolved Hide resolved
pkg/build/rpm_test.go Outdated Show resolved Hide resolved
pkg/build/rpm_test.go Outdated Show resolved Hide resolved
pkg/build/rpm.go Outdated
if rpmSourceDir == "" {
return nil
}
rpmDestDir := b.combustionDir
Copy link
Contributor

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.

Copy link
Contributor Author

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 👍

@ipetrov117
Copy link
Contributor

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.

The doc around the /rpms directory would be of great help both to me and to anyone who is getting familiar with the EIB project.

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 rpm_install.sh script for instance), but most of the code here can be reused. IMO this PR is a step in the right direction.

@ipetrov117
Copy link
Contributor

ipetrov117 commented Nov 14, 2023

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 XX_ prefix as @dbw7 has done here? IMO this would provide additional visibility over the flow of the script execution and will make it easier to track especially when we have more scripts. Furthermore this will decrease any uncertainty of where in the flow to add a new script.

That said, I still do not have the full picture so I might be wrong here. @atanasdinov @jdob @dbw7 wdyt?

@atanasdinov
Copy link
Contributor

You're completely correct.

My comment was indeed to point out that the introduced XX_ scheme in this PR will conflict with the initial alphabetical sorting (which was put there just for determinism purposes). I don't see any issues with starting here and adjusting the other scripts in a follow up. We don't have that many scripts in the first place so the ordering itself shouldn't be hard to figure out.

What we need to consider is how the structure of the scripts dir should look like though. Currently there are scripts on root level, in a message subdirectory and in a grub subdirectory introduced in #39. I suppose we should only "enumerate" the scripts which make it into the final Combustion script.

@jdob
Copy link
Contributor

jdob commented Nov 14, 2023

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.

Copy link
Contributor

@atanasdinov atanasdinov left a 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.

pkg/build/rpm.go Outdated Show resolved Hide resolved
pkg/build/rpm_test.go Outdated Show resolved Hide resolved
pkg/build/rpm_test.go Outdated Show resolved Hide resolved
pkg/build/rpm_test.go Outdated Show resolved Hide resolved
pkg/build/rpm_test.go Outdated Show resolved Hide resolved
pkg/build/rpm_test.go Outdated Show resolved Hide resolved
pkg/build/rpm_test.go Outdated Show resolved Hide resolved
pkg/build/rpm_test.go Outdated Show resolved Hide resolved
@rdoxenham
Copy link
Contributor

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:

zypper ar file:///dev/shm/combustion/config/repo airgap-repo
zypper --no-gpg-checks install -y --force-resolution --auto-agree-with-licenses <list of packages>

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 /rpms directory.

Copy link
Contributor

@atanasdinov atanasdinov left a 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()

pkg/build/rpm_test.go Outdated Show resolved Hide resolved
@dbw7
Copy link
Contributor Author

dbw7 commented Nov 16, 2023

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.

pkg/build/rpm_test.go Outdated Show resolved Hide resolved
finishing touch, processRPMs needs to come before generateCombustionScript so that the rpm script is registered
@atanasdinov atanasdinov merged commit 89f1468 into suse-edge:main Nov 17, 2023
2 checks passed
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.

5 participants