bluehotdog / buff

Like NPM, but for protobuffers

Hi there 👋

buff's Issues

Add package artifact save/delete support

.buffignore - Specify a blacklist for the files/folders to exclude from a package during publish

At the end I used the create ignore which has a default behavior of taking a .ignore file which has the same behavior as .gitignore, I like it and think its good enough for our purposes

Add support for package publish for an existing package

Run CLI tests in CircleCI

Add packaging a buff package

For starters save the compressed tarball to a file, as a milestone towards publishing it

Package name validation

Allowed chars:
a-z0-9[_-.]
max length 30 characters

Define package file

We need to define something like package.json.
I've done some research about this. some of the stuff from npm that might be relevant:

    Access - x
    Name - x
    Description - x
    Keywords - x
    Homepage - x
    Bugs
    License?
    Contributors
        Name
        Email
        URL
    Repository - x
        Type
        URL
        Directory - For mono-repo support
    - Dependencies

Add support for package dependencies

Add buff.toml parser

This should also serve as the basis for the initial spec of buff.toml cc: @BlueHotDog

Users should be able to login/logout

should prob be done after #3

Users should be able to call an login API callback, getting back an authentication token.
I've done a bit of research and i think the following should suffice:

• JWT subject is the user id.
• JWT is signed using the user password as the secret -> this means that invalidating a token is as easy as changing a user password.

Pros:

• Easy to implement, we can also extend later on with expiration fields etc
• Easy to do token invalidation

Cons:

• For each protected access you'll need to do a user lookup, but i think that this needs to happen almost in any case and we can make it super fast.
• Is it a cons to sign using the user password?

Alternatives:
Sign using some hard-coded secret, and store a field on the user marking the last time he changed the password, if the token was issued before the last time the user had changed his pass, then the token is invalid.

what do you think?
@aaron-hak @itayadler

Define API to push a package

Client should be able to push a vaild package.
We need to see if there are any validations we need to do on the server side or everything can be done on the client side.
If we can do everything on the client-side, than we can call this operation Publish
else we need to split between Push and Publish.

Our main operations are:
Lint + Backwards breakage change.
Feels like both can be done on the client-side, but things like backwards compatibility change needs to be also guaranteed on the server-side

Move test files to be along side the implementation files (aside from integration tests)

RegistryService should have its own server instance?

cc @BlueHotDog

Add style lint for Rust (both in VSCode & CircleCI to enforce)

Add validation to package publish

Currently we don't validate a published package at all but accept its artifact binary as is. What sort of validation should we do to the artifact? @BlueHotDog

Validations:
Check if valid tar.gz
Check for size limit 5MB

Add package artifact update support

What do you think of https://github.com/smpallen99/whatwasit @BlueHotDog?
It'll require some changes with how we save the artifact at the moment, as the name we generate to it is static, so we'll need to generate a name preferably with a version

Add code coverage for CLI

Tar.gz should start with the root of the project

currently if BUFF_HOME is a few levels deep, the tar.gz will keep the whole dir structure:
tests/fixtures/test_artifact => ./test_artifact

User management

I suggest 3 levels of hierarchy:
Users: Represent a real person, this is the entity through which you login the system
Teams: Users can belong to a team, teams have access to packages, represents a group of people working on something.
Organizations: A group of teams, By default each org will have the Developers team to which all users will belong by default.

Each package will be owned by either an Org or a User.
Beside having a single owner, package should have multiple teams able to work on it with various permissions.

First iteration:
Create entities representing this hierarchy, minus permissions checks.

Add CLI E2E tests for login and publish

Add info/error/warn messages to CLI commands