This commit is to make the expiration of robot account configurable
1, The expiration could be set by system admin in the configuation page or
by /api/config with robot_token_expiration=60, the default value is 30 days.
2, The expiration could be shown in the robot account infor both on UI and API.
Signed-off-by: wang yan <wangyan@vmware.com>
* Support master role for project member create and update apis
Signed-off-by: He Weiwei <hweiwei@vmware.com>
* Fix description for role_id in swagger.yaml
Signed-off-by: He Weiwei <hweiwei@vmware.com>
Rename the "name" colume in table "replication_policy" and "replication_target" before adding the "UNIQUE" constraint to avoid the upgrade failure
Signed-off-by: Wenkai Yin <yinw@vmware.com>
1. Fix#5102 by checking the existence of name when creating/editing replication rule
2. Add unique constraint to the name of replication policy and target
3. Fix bugs of testing library
Signed-off-by: Wenkai Yin <yinw@vmware.com>
Fixes#6115
As for the change in migration sql file, in 1.7 we'll switch to
jobservice for scheduling "scan all" job. To avoid inconsistency,
this item will be reset and user will need to configure the policy again.
Signed-off-by: Daniel Jiang <jiangd@vmware.com>
Root cause: Use default 'now'::timestamp will not generate timestamp for each transaction,
PG will convert now to a timestamp as soon as the constant is parsed. To fix it, update it
to defult CURRENT_TIMESTAMP, thie setting is the same as default now(), which returns the
start time of current transaction because ther are fuction calls, hey will give the desired
behavior of defaulting to the time of row insertion.
Reference: https://www.postgresql.org/docs/9.6/static/functions-datetime.html#FUNCTIONS-DATETIME-CURRENT
PG version: 9.6.9
It supports Harbor admin to trigger job either manual or
schedule. The job will be populated to job service to execute.
The api includes:
1. POST /api/system/gc
2, GET /api/system/gc/:id
3, GET /api/system/gc/:id/log
4, PUT/GET/POST /api/system/gc/schedule
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.
