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

Documentation: mention that when using with release binary, you should copy the test folder #309

Open
aral opened this issue Apr 5, 2020 · 1 comment

Comments

@aral
Copy link

aral commented Apr 5, 2020

When I first tried to get Pebble running using the binary I downloaded from the releases, it complained about missing files it was looking for. I got it working by copying the test directory from the source repository into the same folder as the Pebble binary. With that, I was able to run Pebble without needing to specify any arguments.

This would be useful to document for people just starting out with Pebble to improve their initial experience.

Related: #308

@atc0005
Copy link

atc0005 commented Jul 26, 2020

@aral: I got it working by copying the test directory from the source repository into the same folder as the Pebble binary. With that, I was able to run Pebble without needing to specify any arguments.

Hi @aral,

I glanced at the current code and it appears there is a default setting for the config file location applied:

configFile := flag.String(
"config",
"test/config/pebble-config.json",
"File path to the Pebble configuration file")

This appears to explain why having the test data alongside the downloaded binary did not require you to explicitly reference the configuration file.


The current example has you installing the binary from source and then remaining in the directory where you ran go install for the next step, which is pebble -config ./test/config/pebble-config.json; the local path reference assumes that your current working directory is still $GOPATH/src/github.com/letsencrypt/pebble.

If you're following those steps exactly that is true, but as you indicate it could probably be called out to make it clearer.

Some thoughts that come to mind:

  • flesh out a subsection specific to the release binaries with a note regarding copying the test data
  • bundle the test data alongside release binaries in an archive file (along with any other core requirements)

It might be worth discussing the latter approach alongside any work to update the README.

I've only recently looked into this project, so my apologies if I am off-base on my feedback.

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

No branches or pull requests

2 participants