Skip to content

Troubleshooting GitLab for Jira Cloud app administration

DETAILS: Tier: Free, Premium, Ultimate Offering: Self-managed

When administering the GitLab for Jira Cloud app, you might encounter the following issues.

For user documentation, see GitLab for Jira Cloud app.

Sign-in message displayed when already signed in

You might get the following message prompting you to sign in to GitLab.com when you're already signed in:

You need to sign in or sign up before continuing.

The GitLab for Jira Cloud app uses an iframe to add groups on the settings page. Some browsers block cross-site cookies, which can lead to this issue.

To resolve this issue, set up OAuth authentication.

Manual installation fails

You might get one of the following errors if you've installed the GitLab for Jira Cloud app from the official marketplace listing and replaced it with manual installation:

The app "gitlab-jira-connect-gitlab.com" could not be installed as a local app as it has previously been installed from Atlassian Marketplace
The app host returned HTTP response code 401 when we tried to contact it during installation. Please try again later or contact the app vendor.

To resolve this issue, disable the Jira Connect Proxy URL setting.

  • In GitLab 15.7:

    1. Open a Rails console.
    2. Execute ApplicationSetting.current_without_cache.update(jira_connect_proxy_url: nil).
  • In GitLab 15.8 and later:

    1. On the left sidebar, at the bottom, select Admin Area.
    2. On the left sidebar, select Settings > General.
    3. Expand GitLab for Jira App.
    4. Clear the Jira Connect Proxy URL text box.
    5. Select Save changes.

If the issue persists, verify that your self-managed GitLab instance can connect to connect-install-keys.atlassian.com to get the public key from Atlassian. To test connectivity, run the following command:

# A `404 Not Found` is expected because you're not passing a token
curl --head "https://connect-install-keys.atlassian.com"

Data sync fails with Invalid JWT

If the GitLab for Jira Cloud app continuously fails to sync data from a self-managed GitLab instance, a secret token might be outdated. Atlassian can send new secret tokens to GitLab. If GitLab fails to process or store these tokens, an Invalid JWT error occurs.

To resolve this issue on your self-managed GitLab instance:

Depending on how you installed the app, you might want to check the following:

  1. In Jira, on the top bar, select Apps > Manage your apps.
  2. Expand GitLab for Jira (gitlab.com).
  3. Select Get started.
  4. Select Change GitLab version.
  5. Select GitLab.com (SaaS), then select Save.
  6. Select Change GitLab version again.
  7. Select GitLab (self-managed), then select Next.
  8. Select all checkboxes, then select Next.
  9. Enter your GitLab instance URL, then select Save.

If this method does not work, submit a support ticket if you're a Premium or Ultimate customer. Provide your GitLab instance URL and Jira URL. GitLab Support can try to run the following scripts to resolve the issue:

# Check if GitLab.com can connect to the self-managed instance
checker = Gitlab::TcpChecker.new("gitlab.example.com", 443)

# Returns `true` if successful
checker.check

# Returns an error if the check fails
checker.error
# Locate the installation record for the self-managed instance
installation = JiraConnectInstallation.find_by_instance_url("https://gitlab.example.com")

# Try to send the token again from GitLab.com to the self-managed instance
ProxyLifecycleEventService.execute(installation, :installed, installation.instance_url)

Failed to update the GitLab instance

When you set up the GitLab for Jira Cloud app, you might get a Failed to update the GitLab instance error after you enter your self-managed instance URL.

To resolve this issue, ensure all prerequisites for your installation method have been met:

If you have configured a Jira Connect Proxy URL and the problem persists after checking the prerequisites, review Debugging Jira Connect Proxy issues.

If you're using GitLab 15.8 and earlier and have previously enabled both the jira_connect_oauth_self_managed and the jira_connect_oauth feature flags, you must disable the jira_connect_oauth_self_managed flag due to a known issue. To check for these flags:

  1. Open a Rails console.

  2. Execute the following code:

    # Check if both feature flags are enabled.
    # If the flags are enabled, these commands return `true`.
    Feature.enabled?(:jira_connect_oauth)
    Feature.enabled?(:jira_connect_oauth_self_managed)
    
    # If both flags are enabled, disable the `jira_connect_oauth_self_managed` flag.
    Feature.disable(:jira_connect_oauth_self_managed)

Debugging Jira Connect Proxy issues

If you set Jira Connect Proxy URL to https://gitlab.com when you set up your instance, you can:

  • Inspect the network traffic in your browser's development tools.
  • Reproduce the Failed to update the GitLab instance error for more information.

You should see a GET request to https://gitlab.com/-/jira_connect/installations.

This request should return a 200 OK, but it might return a 422 Unprocessable Entity if there was a problem. You can check the response body for the error.

If you cannot resolve the issue and you're a GitLab customer, contact GitLab Support for assistance. Provide GitLab Support with:

  • Your self-managed instance URL.
  • Your GitLab.com username.
  • Optional. The X-Request-Id response header for the failed GET request to https://gitlab.com/-/jira_connect/installations.
  • Optional. A HAR file you've processed with harcleaner that captures the issue.

GitLab Support can then investigate the issue in the GitLab.com server logs.

GitLab Support

NOTE: These steps can only be completed by GitLab Support.

Each GET request made to the Jira Connect Proxy URL https://gitlab.com/-/jira_connect/installations generates two log entries.

To locate the relevant log entries in Kibana, either:

  • If you have the X-Request-Id value or correlation ID for the GET request to https://gitlab.com/-/jira_connect/installations, the Kibana logs should be filtered for json.meta.caller_id: JiraConnect::InstallationsController#update, NOT json.status: 200 and json.correlation_id: <X-Request-Id>. This should return two log entries.

  • If you have the self-managed URL for the customer:

    1. The Kibana logs should be filtered for json.meta.caller_id: JiraConnect::InstallationsController#update, NOT json.status: 200 and json.params.value: {"instance_url"=>"https://gitlab.example.com"}. The self-managed URL must not have a leading slash. This should return one of the log entries.
    2. Add the json.correlation_id to the filter.
    3. Remove the json.params.value filter. This should return the other log entry.

For the first log:

  • json.status is 422 Unprocessable Entity.
  • json.params.value should match the self-managed GitLab URL [[FILTERED], {"instance_url"=>"https://gitlab.example.com"}].

For the second log, you might have one of the following scenarios:

  • Scenario 1:

    • json.message, json.jira_status_code, and json.jira_body are present.
    • json.message is Proxy lifecycle event received error response or similar.
    • json.jira_status_code and json.jira_body might contain the response received from the self-managed instance or a proxy in front of the instance.
    • If json.jira_status_code is 401 Unauthorized and json.jira_body is (empty):
      • Jira Connect Proxy URL might not be set to https://gitlab.com.

      • If a reverse proxy is in front of your self-managed instance, the Host header sent to the self-managed instance might not match the reverse proxy FQDN. Check the Workhorse logs on the self-managed instance:

        grep /-/jira_connect/events/installed /var/log/gitlab/gitlab-workhorse/current

        The output might contain the following:

        {
          "host":"gitlab.mycompany.com:443", // The host should match the reverse proxy FQDN entered into the GitLab for Jira Cloud app
          "remote_ip":"34.74.226.3", // This IP should be within the GitLab.com IP range https://docs.gitlab.com/ee/user/gitlab_com/#ip-range
          "status":401,
          "uri":"/-/jira_connect/events/installed"
        }
  • Scenario 2:

    • json.exception.class and json.exception.message are present.
    • json.exception.class and json.exception.message contain whether an issue occurred while contacting the self-managed instance.

Failed to link group

When you link a group, you might get the following error:

Failed to link group. Please try again.

A 403 Forbidden is returned if the user information cannot be fetched from Jira because of insufficient permissions.

To resolve this issue, ensure the Jira user that installs and configures the app meets certain requirements.

This error might also occur if you use a rewrite or subfilter with a reverse proxy. The app key used in requests contains part of the server hostname, which some reverse proxy filters might capture. The app key in Atlassian and GitLab must match for authentication to work correctly.

Failed to load Jira Connect Application ID

When you sign in to the GitLab for Jira Cloud app after you point the app to your self-managed instance, you might get the following error:

Failed to load Jira Connect Application ID. Please try again.

When you check the browser console, you might also see the following message:

Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://gitlab.example.com/-/jira_connect/oauth_application_id. (Reason: CORS header 'Access-Control-Allow-Origin' missing). Status code: 403.

To resolve this issue:

  1. Ensure /-/jira_connect/oauth_application_id is publicly accessible and returns a JSON response:

    curl --include "https://gitlab.example.com/-/jira_connect/oauth_application_id"
  2. If you installed the app from the official Atlassian Marketplace listing, ensure Jira Connect Proxy URL is set to https://gitlab.com without leading slashes.

Missing required parameter: client_id

When you sign in to the GitLab for Jira Cloud app after you point the app to your self-managed instance, you might get the following error:

Missing required parameter: client_id

To resolve this issue, ensure all prerequisites for your installation method have been met: