* add common config and encryption passwd
Adds a provider-independent configuration handler, and the
the encryption password config property. The password is used
to encrypt and decrypt the kopia repository properties file.
* fix corso_password in ci.yml
* actually use the corso password in testing
* replace passwd in ci.yml with a secret
* ci.yml secret typo fix
A small collection of changes and code cleanup to successfully run
'corso repo init s3' manually. Adds a default s3 url (might want
this configurable for local testing) and aws session token support.
* add e2e wiring of cli to kopia
Now that pkg/storage and internal/kopia are in place, we
can wire up the init flow from the cli all the way to kopia. Testing
harness for this functionality still needs investigation afterward.
* factor out awsVars struct for s3Cfg
* adds kopia pkg to handle integration (#25)
internal/kopia will be used to abstract all kopia integration in a
central location.
* defer blob.Storage closure in kopia
blob.Storage objects must get closed at the end of their usage.
This currently isn't getting called.
* introduces storage pkg (#25)
Adds a new package /pkg/storage. Storage is used to
communicate storage provider information throughout the corso
app. In particular, it allows per-provider data to cross interface
boundaries without slicing their details.
* use consts for s3 config keys
Adds the s3 provider set to the repo cli commands. Flag, env
vars, and other configuration is still incomplete and will require
iteration. But this sets us up for quick testing of the commands.
* adds docs/CLI.md
Introduces the cli command documentation.
* extending cli.md with design discussion
* migrate cli.md into docusaurus docs (#11)
Move the CLI.md file into docusaurus so that it appears
as part of the documentation page.
* remove cli version, settings.json (#11)
Remove /.vscode/settings.json and the versioning info from
/docs/cli.md.
* introduce repository api scaffold with s3 (#6)
introduces the public repository package in /pkg, with a
skeleton implementation for generating the s3 provider config
and boilerplate for where that usage gets centralized.
* condense init/connect to single action
A double-pass NewRepo() && Connect() allows Repository structs
to exist independent guarantees that their usage will be successful.
This hides the struct generation within the Connect and Initialize
funcs so that the construction and guarantees can occur as
a single process.
Mac uses low group IDs for the default user, which would cause groupadd
to fail as the group already existed. Only make a new group if it
doesn't already exist.
This does raise other questions though as now we are technically having
the container run with a "services" group.
Now reflects the fact that this will be cloned from github. Also place
in source directory so that all packages in the project don't need to be
`src/foo`.
* Mounts the current repo's code in the proper golang path in the
container
* Container will be destroyed when container is exited
* User will start in the repo's code directory in the container
* New container will have deps known at the time the container was made
* If deps change a lot, rebuild/save current container image as deps
are outside the directory mount
* Deps are not explicitly listed in the container Dockerfile or script
as go mod is expected to manage them for us
* Automatically creates a container user with UID/GID of the current
user to avoid file ownership issues
* Expects go get/go mod to be used to handle application dependencies
* Expects users to use a volume mount to make code visible to the
container
* Add a user (with the option of having the same UID/GID as current
user) to avoid weird file owners when building things in the container
as golang usually runs as root
