them to GCS.

We don't always have a new one, and under load there might be "batches" of entries
all integrated into the same STH. This means there is no guaranteed frequency of updates
or even a guarantee that every index will exist.

The values (and timestamps) should be monotonically increasing though.

Signed-off-by: Dan Lorenc <dlorenc@google.com>

This will allow us to use types.NewEntry() to unmarshal returned
values in clients.

Signed-off-by: Dan Lorenc <dlorenc@google.com>

Since the API key can be specified as an environment variable and could
be thought of as an authentication credential, it should not be included
in the path to the created entry in the log.

Previously we simply appended the new entry's UUID to the full URL,
which was incorrect if an API key was specified as a query parameter.

Fixes #182

Signed-off-by: Bob Callaway <bcallawa@redhat.com>

By using viper.GetString(flag), viper will return the values of that
argument from a precedence order (including CLI arguments). However, if
a value was passed in through an environment variable or as a value in
the config file, it would skip the validation step since that logic was
defined against the FlagSet for command line arguments.

This change causes validation to be done across all input methods.

Fixes #157

Signed-off-by: Bob Callaway <bcallawa@redhat.com>

I noticed this when running some tests locally.

Also check it in the test.

Next up is a JSON output mode to make testing/scripting easier.

Signed-off-by: Bob Callaway <bcallawa@redhat.com>

Co-authored-by: Dan Lorenc <dlorenc@google.com>

These require the minisign binary to be installed.

- Run through the get flow, make sure the output is well structured
- Call loginfo, make sure there are no errors.

This way we don't have to worry about existing entries in the logs.