Paul Campbell
b5a1dd4326
Some checks failed
ci/woodpecker/push/build Pipeline failed
ci/woodpecker/push/todo-check Pipeline was successful
ci/woodpecker/push/release Pipeline was successful
ci/woodpecker/push/docker Pipeline failed
ci/woodpecker/manual/build Pipeline failed
ci/woodpecker/manual/release Pipeline was successful
ci/woodpecker/manual/docker Pipeline was successful
ci/woodpecker/manual/todo-check Pipeline was successful
ci/woodpecker/cron/release Pipeline was successful
ci/woodpecker/cron/todo-check Pipeline failed
ci/woodpecker/cron/docker Pipeline was successful
ci/woodpecker/cron/build Pipeline was successful
|
||
---|---|---|
.cargo | ||
.git-hooks | ||
.woodpecker | ||
src | ||
.gitignore | ||
bacon.toml | ||
Cargo.toml | ||
default.toml | ||
Dockerfile | ||
Dockerfile.builder | ||
justfile | ||
LICENSE | ||
README.md | ||
renovate.json | ||
server-default.toml |
git-next
Automated and minimal merge-queue ideal for a solo developer (later versions may support teams)
Currently this will mostly for myself when working on projects by myself. I'd like to reduce the overhead of PRs, but still maintain CI verification of each commit/patch set.
The main
branch remains the ready-to-deploy version of the project.
I would then have a dev
branch where I would do all of my work.
As a commit is added, as long as it matches a conventional commit message and isn't marked as WIP:
, the next
branch will advance from the current main
commit to this next commit where it will be submitted to CI. This may or may not involve a PR. If it passes CI then the main
branch will fast-forward to that commit (i.e. to next
which should be a single step). The next commit on the dev
branch will then be considered.
The application would initially integrate with only with ForegeJo via it's API to interact with the main
, next
and dev
branches and to review the status check results for each commit or PR.
Before:
*1--*2--*3--*4--*5 main/next
\--*6--*7--*8--*9 dev
During CI:
*1--*2--*3--*4--*5 main
\--*6 next
\--*7--*8--*9 dev
After CI passes for *6:
*1--*2--*3--*4--*5--*6 main/next
\--*7--*8--*9 dev
The dev
branch should never need to rebase onto main
as main
is only ever advancing along the dev
branch as each commit passes CI.
Developing on git-next
Before you start committing, run the just install-hooks
command to setup the Git Hooks. Get Just
Design
- CLI to initialise the Repo (e.g. create config file)
- Server that monitors a collection of repos via the Forge APIs
The CLI and the Server could be the same executable taking different commands to decide behaviour.
e.g.
(assuming the command is git-next
)
Initialise a repo:
$ git next init
This would create a default configuration file: .git-next.toml
.
Initialise a Server:
$ git next server init
This would create a configuration file git-next-server.toml
for running the server. It would include details of the repos to be monitored and any credentials to be used.
Start a Server:
$ git next server start
This would start a server using the configuration file in the current directory.