search

git-ecosystem / git-bundle-server

A web server & management CLI to host Git bundles for use with Git's "bundle URIs" feature
Other
43 stars 20 forks source link

`git-bundle-server` CLI Part 2: collapse base bundle and the `update-all` subcommand #3

Closed derrickstolee closed 2 years ago

derrickstolee commented 2 years ago

Based on #2.

The update subcommand now notices when there are more than 5 bundles and squashes the oldest ones into a new "base" bundle. The bundle is renamed but keeps the maximum creation token from that group of bundles.

Modified some of the parameters, especially those in the git package to avoid cyclic package dependencies. Also used struct pointers more often.

Repository routes are now stored in a new routes file (currently plaintext with line-separated list of routes).

The new update-all subcommand runs the update subcommand on all registered routes. It also passes any remaining arguments down to the subcommand, which will help when we add the --daily and --hourly options.

derrickstolee commented 2 years ago

One thing I always find particularly invaluable when developing software quickly is a set of automated tests. Do you think it would make sense to start this soon, or would it rather slow you down at this stage?

As I'm building the features, I'm benefitting from the fact that every method prototype can be changed quickly. I have some end-to-end scripts that allow me to manually check that things are working as I expect, but until I have a more complete view of things I'll need to hold off on a test suite. In the (internal) tracking issue I have an item for creating a test strategy after we reach a prototype that can be used for evaluation.

derrickstolee commented 2 years ago

One thing I always find particularly invaluable when developing software quickly is a set of automated tests. Do you think it would make sense to start this soon, or would it rather slow you down at this stage?

As I'm building the features, I'm benefitting from the fact that every method prototype can be changed quickly. I have some end-to-end scripts that allow me to manually check that things are working as I expect, but until I have a more complete view of things I'll need to hold off on a test suite. In the (internal) tracking issue I have an item for creating a test strategy after we reach a prototype that can be used for evaluation.

All of that said, I've been playing around with getting automated builds so at least we get compiler checks as PRs are going in. However, I continue to struggle with Go's build environment and package rules. Work is ongoing in the stolee/cli-3 branch.