Uploaded image for project: 'Bitbucket Data Center'
  1. Bitbucket Data Center
  2. BSERV-2818

The latest custom JIRA issue key regex is not used to reindex the old commits

    • 8
    • We collect Bitbucket feedback from various sources, and we evaluate what we've collected when planning our product roadmap. To understand how this piece of feedback will be reviewed, see our Implementation of New Features Policy.

      Steps to reproduce

      1. Do not modify Dintegration.jira.key.pattern (previosuly Dstash.jira.key.pattern - see STASH-2784)
      2. Integrate Bitbucket Server with JIRA
      3. Perform a commit to Bitbucket Server with the comment 'TST3-123' (The issue column does not have JIRA issue link)
      4. Stop Bitbucket Server
      5. Modify JIRA custom issue key regex by editing the setenv script:
        JVM_SUPPORT_RECOMMENDED_ARGS="-Dintegration.jira.key.pattern=\"b([a-zA-Z][a-zA-Z0-9]+-\d+)\""
        
      6. Start Bitbucket Server
      7. Perform another commit to Bitbucket Server with the comment 'TST3-123'

      Expected Results

      Previously pushed commits have the issue link.

      Actual Results

      Only the latest commit has the issue link.

          Form Name

            [BSERV-2818] The latest custom JIRA issue key regex is not used to reindex the old commits

            rodolfo added a comment -

            Would the following fix this issue ?

            1. Create a backup before continuing.
            2. Shut down Bitbucket Server.
            3. Remove the contents of the <BITBUCKET_HOME>/shared/data/snapshots directory.
            4. Restart Bitbucket Server.
            5. Push to the repository with the JIRA issue key in the commit message to force a reindex of the data.

            Source: Reindex JIRA issue keys

            rodolfo added a comment - Would the following fix this issue ? Create a backup before continuing. Shut down Bitbucket Server. Remove the contents of the <BITBUCKET_HOME>/shared/data/snapshots directory. Restart Bitbucket Server. Push to the repository with the JIRA issue key in the commit message to force a reindex of the data. Source: Reindex JIRA issue keys

            MattS added a comment -

            Problem still exists in 2.4.2. I think it's more than minor because there is no work around to cause previous commit messages to be rescanned. Deleting the idx-snapshot doesn't do it apparently. The other workaround at https://confluence.atlassian.com/display/STASHKB/Git+Commits+Are+Not+Linking+to+JIRA+Tickets+Due+to+Corrupted+Indexes (which loses pull request info) is very slow for more than a dozen repos.

            Please provide a way to reindex each repo individually, and also a global repo reindex

            MattS added a comment - Problem still exists in 2.4.2. I think it's more than minor because there is no work around to cause previous commit messages to be rescanned. Deleting the idx-snapshot doesn't do it apparently. The other workaround at https://confluence.atlassian.com/display/STASHKB/Git+Commits+Are+Not+Linking+to+JIRA+Tickets+Due+to+Corrupted+Indexes (which loses pull request info) is very slow for more than a dozen repos. Please provide a way to reindex each repo individually, and also a global repo reindex

            Short-term we should allow users to customize the JIRA issue key pattern through STASH-HOME/stash-config.properties as well. This would make upgrades easier; no need to modify the setenv.sh.

            Michael Heemskerk (Inactive) added a comment - Short-term we should allow users to customize the JIRA issue key pattern through STASH-HOME/stash-config.properties as well. This would make upgrades easier; no need to modify the setenv.sh.

            A partial workaround is to delete the files in STASH_HOME/caches/idx-snapshots/<repo-id>. This will force the indexer to start indexing from the first commit again. Unfortunately, this is not the same as a real 're-index' because previously indexed JIRA keys are not removed.

            You can retrieve the repository ID through the REST api: https://stash.yourdomain.com/rest/api/latest/projects/<project-key>/repos/<repo-slug>

            Long-term we should:

            • retrieve the regex pattern(s) from connected JIRA servers. When we get a pattern that is not the default pattern, we should re-index all(?) repositories or add a banner to the admin screens.
            • add the option to re-index a repository from the Repository Settings and REST.

            Michael Heemskerk (Inactive) added a comment - A partial workaround is to delete the files in STASH_HOME/caches/idx-snapshots/<repo-id> . This will force the indexer to start indexing from the first commit again. Unfortunately, this is not the same as a real 're-index' because previously indexed JIRA keys are not removed. You can retrieve the repository ID through the REST api: https://stash.yourdomain.com/rest/api/latest/projects/<project-key>/repos/<repo-slug> Long-term we should: retrieve the regex pattern(s) from connected JIRA servers. When we get a pattern that is not the default pattern, we should re-index all(?) repositories or add a banner to the admin screens. add the option to re-index a repository from the Repository Settings and REST.

            Problem still exists in 2.1.2.

            We forgot to change the setenv script after upgrading stash.
            We made some commits before noticing the issue.

            After changing the setenv script the new pattern is used; new commits are linked to the jira issues.
            Old commits are still not linked.

            Is there a workaround to force relinking of old commits?

            Deleted Account (Inactive) added a comment - Problem still exists in 2.1.2. We forgot to change the setenv script after upgrading stash. We made some commits before noticing the issue. After changing the setenv script the new pattern is used; new commits are linked to the jira issues. Old commits are still not linked. Is there a workaround to force relinking of old commits?

            jens added a comment -

            mheemskerk, is this related to the work that you've done recently on indexing the changeset? Does it fix this issue or do we require re-indexing for this to work.

            jens added a comment - mheemskerk , is this related to the work that you've done recently on indexing the changeset? Does it fix this issue or do we require re-indexing for this to work.

              Unassigned Unassigned
              klfoong Foong (Inactive)
              Votes:
              14 Vote for this issue
              Watchers:
              19 Start watching this issue

                Created:
                Updated: