Skip to content

CPIO files utility#523

Open
davidcassany wants to merge 2 commits into
SUSE:mainfrom
davidcassany:cpio_files
Open

CPIO files utility#523
davidcassany wants to merge 2 commits into
SUSE:mainfrom
davidcassany:cpio_files

Conversation

@davidcassany

Copy link
Copy Markdown
Contributor

This PR extends the runner interface to support piped input and outputs and it also creates a small internal utility to create and extract CPIO files.

@davidcassany
davidcassany requested a review from a team as a code owner July 8, 2026 09:29
@davidcassany

Copy link
Copy Markdown
Contributor Author

This PR introduces a call to cpio utility in the scope of elemental3 customize so that this implies adding cpio rpm as a requirement of elemental3 package to ensure it is present in the elemental3 image.

I did not consider using a golang library (like this one) as I considered it was not worth adding an extra go dependency while having a fully supported cpio tool in almost any linux OS out there.

Signed-off-by: David Cassany <dcassany@suse.com>
Signed-off-by: David Cassany <dcassany@suse.com>

@atanasdinov atanasdinov left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Great submission! I got a few comments and questions, but LGTM overall.

Comment thread pkg/sys/mock/runner.go
return r.Run(command, args...)
}

func (r *Runner) RunContextWithPipe(

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

ReturnError/SideEffect values are being ignored. Do we want to add them as a proper unit test failure for mocked cpio errors?

Comment thread pkg/sys/mock/runner.go

callErrChan := make(chan error, 1)
go func() {
_, e := io.Copy(stdout, pr)

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

I believe this can panic if stdout is not set. Is it an issue?

Expect(r.RunContextWithPipe(context.Background(), callback, buff, nil, workDir, nil, "cat", "-", "secondLine")).To(Succeed())
Expect(buff.String()).To(ContainSubstring("First line\nSecond line\n"))
})
It("runs a command getting input from a pipe in a specific working directory", func() {

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

The test name is duplicated from above.

Comment thread pkg/sys/runner/runner.go

if err = stdinPipeFn(stdinPipe); err != nil {
_ = stdinPipe.Close()
_ = cmd.Wait()

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

This call should contain the real error that we need to report. When failing, err = stdinPipeFn(stdinPipe) is likely to contain io: read/write on closed pipe because the subprocess would exit before consuming all of stdin.

One approach could be to keep both errors in the propagated error, e.g. return fmt.Errorf("callback returned an error: %w, pipe closed with: %w", cErr, err).

Have you ran into such issue?

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.

2 participants