Troubleshoot
If you need further assistance setting up GitOps, feel free to reach us.
Committed migration file does not trigger issue creation
When a migration file is committed to the VCS, VCS will send a webhook event to Bytebase. There are two error categories:
-
Bytebase has received webhook events
-
Bytebase has not received any webhook event
Bytebase has received webhook events
In this case, if you visit your project activity page, you should find an activity event suggesting Bytebase has received the webhook event. However, the committed file doesn't match the configured path and the event is ignored.
You should check the committed file conforms exactly to the naming convention and the directory structure conforms to the layout. Bytebase file name match is case-sensitive. Below screenshot shows some common mistakes:
- â File name mismatches.
- â File name case mismatches.
- â Environment id mismatches. Note we should match
Environment ID
instead ofEnviornment Name
. - â Match.
Bytebase has not received any webhook event
In this case, you should visit the your VCS provider's webbook page and check the webhook event history.
-
Make sure Bytebase has configured a proper External URL.
-
Make sure that configured URL is network accessible from VCS.
You can turn on debug mode. Then on the GitOps settings page, visit the linked VCS webhook page to check the details.
Failed to create webhook xxx, status code: 422 for GitLab
If you configure External URL with the private IP such as 10.0.0.0/8
, 172.16.0.0/12
, 192.168.0.0/16
, you will need to enable Allow requests to the local network from webhooks and integrations first.
OAuth CORS error with old GitLab version
When using old GitLab version (e.g. 9.4.0) to setup VCS integration, you may encounter OAuth error like this one:
This is a common problem in the old GitLab verison:
- https://gitlab.com/gitlab-org/gitlab-foss/-/issues/19470
- https://gitlab.com/gitlab-org/gitlab/-/issues/300077
Verify the problem
Open your browser devtool with F12
, check the Network
section. If the latest token request with CORS error
status, we can be certain that it's the /oauth/token
api CORS error inside GitLab.
Potential solution
We cannot change GitLab source code to add the Access-Control-Allow-Origin: *
to /oauth/token
response header, but can use Nginx as a reverse proxy for GitLab (the other proxy service works the similar way).
CORS solution with Nginx
Add add_header
codes directive to the base path location block of your Nginx GitLab configuration file.
server {
...
location / {
add_header 'Access-Control-Allow-Credentials' 'true';
add_header 'Access-Control-Allow-Headers' 'Authorization,Accept,Origin,DNT,X-CustomHeader,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Content-Range,Range';
add_header 'Access-Control-Allow-Methods' 'GET,POST,OPTIONS,PUT,DELETE,PATCH';
if ($request_method = 'OPTIONS') {
add_header 'Access-Control-Allow-Origin' $http_origin;
add_header 'Access-Control-Max-Age' 1728000;
add_header 'Content-Type' 'text/plain charset=UTF-8';
add_header 'Content-Length' 0;
return 204;
}
if ($request_method != GET) {
add_header 'Access-Control-Allow-Origin' '*';
}
...
}
...
}
Run the following command to reload your updated config file.
sudo nginx -s reload
Afterwards, try the GitLab setup again.