This commits fixes the "gob: name not registered for interface" error when restarting Harbor by registering models.User
Signed-off-by: Wenkai Yin <yinw@vmware.com>
append chart server related config options to the supporting list of adminserver
provide chart server related config access method in the API layer
update prepare script and ui env template file to enable cache driver config for chart server API
append flag info in the systeminfo API to indicate if chart server is deployed with Harbor
refactor the response rewriting logic to return structual error object
add api init method to initilizing objects required in API handlers
chage owner of the storage folder
update offline/online package scripts in Harbor-Util.robot
add /chartrepo after /api
add /chartrepo before /index.yaml,/:repo/index.yaml and /:repo/charts/:filename
add debug messages to the potential debug points
add more supporting mime types "multipart/form-data", "application/octet-stream" to the API endpoints
update travis file to inject ENV for UT cases of chart repo
This commit make update to remove the code from ui container to init the
DB schema. As UI has dependency on admin server, so it's safe to assume
adminserver has to be ready first. Regardless the setting of the config
store of admin server, it will try to access and intialize the schema of
database.
By default Harbor will call catalog API of registry and sync the result to DB, this becomes problematic when registry is configured to custom storage service, there maybe inconsistent result and the whole process may be very time consuming.
So in this commit a env var SYNC_REGISTRY is introduced if user want Harbor to sync the repo when it starts up, by default it's false.
This commit fixes#5040, the harbor-db image will only contain empty
databases, and harbor ui container will use migrate tool to run initial
SQL scripts to do initialization. This is helpful for the case to
configure Harbor against external DB or DBaaS like RDS for HA deployment
However, this change will results some confusion as there are two tables
to track schema versions have been using alembic for migration, for this
release we'll try to use alembic to mock a `migration` table during
upgrade so the migrator will be bypassed, in future we'll consider to
consolidate to the golang based migrator.
Another issue is that the UI and adminserver containers will access DB
after start up in different congurations, can't ensure the sequence, so
both of them will try to update the schema when started up.
Add filter for all API endpoints to allow the POST requests which have
application/json header.
Make update to UI code to make sure all requests contain the header.
