feat: Publish API

[sdankel]

Related #9

This PR exposes a /publish endpoint that accept all metadata about a package and stores it in the database. There is also a bit of refactoring and code cleanup.

This PR also:

• adds an API for showing the most recent packages/versions published, and populates a rudimentary home screen/dashboard for forc.pub
• support for .env.local which @zees-dev had previously suggested
• switched to timestamptz and chrono as @zees-dev suggested
• better error handling, now the server surfaces the detailed error message to the client
  Closes Replace SystemTime with something timezone-aware #21

There is still more to do on the publishing front:

1. Publish to a github repo for forc indexing
2. Publish to a new block explorer endpoint (dependent on @FuelLabs/frontend )

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
forc-pub	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Jan 12, 2025 11:47pm

[zees-dev]

in quickstart(s) we should try to push for ephemeral tooling - which is most cases is containers.
E.g. postgres in container; pgadmin UI as a way to view the db, provide a docker-compose.yml which would spin up db, pgadmin, and run startup script (or inline) which would perform the migrations.
This would give external dev(s) a great quick start point to get the whole infra running locally.

Can be in future PR(s) btw.

[sdankel]

I haven't really used pgadmin; I have used psql but I prefer DBeaver. I think it's up to the developer what DB client they want to use. I could mention more of them here or just omit this section. Why do you think pgadmin is better/ should be recommended?

The migrations are performed automatically by diesel when the server starts.

This would give external dev(s) a great quick start point to get the whole infra running locally.

There are two scripts that serve this purpose:

• start_local_db.sh: starts the DB in docker
• start_local_server.sh: starts both the DB and server in docker, in a shared network

docker-compose would be better but I don't have much experience writing it and found it more convenient to write/user these bash scripts. We should circle back to it: #24

[zees-dev]

pgadmin is good just because everything can be run via docker-compose (it's all ephemeral).
Agree about the db-client being a developer opinion/option; I just think we should provide something which is ephemeral (not required on the machine) - even better if can just be provided by docker (whatever it is - pgadmin comes to mind first for me atleast).

[zees-dev]

Nice makes sense; yeap an issue is good start point - someone else (or even myself) can look into it 😄

[zees-dev]

Great work! 🚀
Suggested a few improvements; core functionality is there though!

[JoshuaBatty]

Great work on this.