In v1.7.0, it creates an record for scan all but without cron string, just update the record with the cron in properties.
Signed-off-by: wang yan <wangyan@vmware.com>
* add scan all and gc schedule migration
Signed-off-by: wang yan <wangyan@vmware.com>
* Fix gofmt errors
Signed-off-by: wang yan <wangyan@vmware.com>
* Update code according to review comments
Signed-off-by: wang yan <wangyan@vmware.com>
* remove convertschedule return name just return value
Signed-off-by: wang yan <wangyan@vmware.com>
1. handle the public/private property when creating the projects
2. extend the length of access_secret
3. update the task status by using orm functions
Signed-off-by: Wenkai Yin <yinw@vmware.com>
This commit introduces a solution to workaround the restriction of project creation API: only normal users can create projects
Signed-off-by: Wenkai Yin <yinw@vmware.com>
As CLI does not support oauth flow, we'll use secret for help OIDC user
to authenticate via CLI.
Add column to store secret and token, and add code to support
verify/refresh token associates with secret. Such that when the user is
removed from OIDC provider the secret will no longer work.
Signed-off-by: Daniel Jiang <jiangd@vmware.com>
1. Add operation property for tasks
2. Add trigger property for executions
3. Update the getting registry info API to allow passing 0 as ID to get the info of local Harbor registry
Signed-off-by: Wenkai Yin <yinw@vmware.com>
This commit updates the upgrade sql script to fix#6698: cannot recreate the same name replication policy after it is deleted
Signed-off-by: Wenkai Yin <yinw@vmware.com>
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.
