back to all blogsSee all blog posts

Finding the Open Liberty fix pack from a GitHub issue

image of author
Barbara Jensen on Jun 18, 2021
community , developer-experience ,
Post available in languages:

Open Liberty developers sometimes debug problems by finding a GitHub issue that addresses the problem that they are experiencing. You can use the information in Open Liberty GitHub issues to determine which Open Liberty fix packs contain a fix for the problems that are described in the issue.

In this post, we’ll look at the ways you can find Open Liberty fix pack information from a GitHub issue and walk through a couple example scenarios.

There are at least three methods for finding fix pack information:

  • Method 1: If the issue has the release bug label, you might find the issue in the Fix list for IBM WebSphere Application Server Liberty - Continuous Delivery

    • If the release bug label was added to an issue before its first fix pack was delivered, the issue will be in the fix list.

    • Some issues that have the release bug label are not in the fix list. In these cases, the label was added after its fix pack was delivered and the issue was not manually added to the fix list.

    • Although this list applies to WebSphere Liberty, the corresponding fix pack number for Open Liberty contains the same updates, provided the function exists in Open Liberty.

  • Method 2: Find the fix pack information in the release:yynnn issue label.

    • If the release bug label was added to an issue after its first fix pack was delivered, the release:yynnn label might not appear on the issue.

    • Developers sometimes add the release:yynnn label to an issue after fix pack delivery.

  • Method 3: Find the fix pack information in the last commit in the last pull request for the issue.

    • If you cannot find the issue in the fix list and the issue doesn’t have a release:yynnn label, you can use this method.

    • You can also use this method as second source to verify the information in an issue label.

The following sections demonstrate how to use a combination of these methods to find and verify fix pack information.

Finding the fix pack for an issue that has a 'release bug' label

Suppose that you have found issue 14975 OIDC RP: creating a subject with allowCustomCachKey=false results in a subject that includes a cache key that matches the problem that you are experiencing.

  • When you display the issue, you’ll see the following in the Labels list:

    finding 14975 a

  • There are two things to note here:

    1. The release bug label is in the issue, therefore the issue should appear in the fix list.

    2. The release:21001 label is on the issue. This means that the fix for this issue should be first available in 21.0.0.1.

Let’s verify the release:21001 label from the Liberty fix list:

  1. Navigate to Fix list for IBM WebSphere Application Server Liberty - Continuous Delivery

  2. Search for 14975:

    finding 14975 b

  3. Search back to find the fix pack:

    finding 21001

Finding the fix pack for an issue that doesn’t have a 'release bug' label

Suppose that you have found issue 15987 OIDC state cookie cannot be read by another JVM in collective w/socal login TS004966274 that matches the problem that you are experiencing.

  • When you display the issue, you’ll see the following in the Labels list:

    finding 15987 a

  • There are two things to note here:

    1. The release bug label is not in the issue, therefore the issue will not appear in the fix list.

    2. The release:21004 label is on the issue. This means that the fix for this issue should be first available in 21.0.0.4.

When you don’t see the release bug label on an issue, you most likely won’t see a release:yynnn label. Don’t assume that the issue that you are looking at isn’t in a fix pack just because you do not see the release:yynnn label. If the issue is closed, it should be in a shipped or future fix pack. You can find the fix pack for the issue from the from the last commit in the last pull request for the issue.

Let’s verify the release:21004 label from the last PR in the issue:

  1. Navigate to the 15987 issue on GitHub.

  2. Find the pull request (PR) that fixes the issue. For this issue, it is 16150

    finding 15987 b

    • If the PR is not Merged, then the fix for the issue is not delivered yet.

  3. Click the link for PR #16150

  4. Search the text of the PR for revert " (revert, space, double quotation mark)

    • Look for a revert message that is similar to the following example:

      finding revert 1

    • If you find that the PR has been reverted, you cannot follow the rest of these simple steps for your issue. For more information, see Finding the fix pack for a PR that is reverted.

  5. If the PR is not reverted, click the Commits tab

    finding 16150 a

  6. Click the last commit for the PR (in this PR, there is only one): 843c128

    finding 16150 b

  7. In the Commits tab, look for a list of release tags in the form gm-yynnn, which indicates the releases that this PR was included in, starting from the newest to oldest. The last tag in the list is the first release in which the PR was included. In this case, it is gm-21.0.0.4:

    finding 16150 c

    • If no fix packs are listed, then the issue has not yet been delivered in a fix pack.

Finding the fix pack for a PR that is reverted

  • When you try to find the fix pack for an issue, you might run into a PR that is reverted. A reverted PR can be much more challenging to track.

  • You need to find another issue that reintroduces the fix that was reverted. You can sometimes determine this information by searching in a PR for a reintroduce message that identifies an issue that reintroduces the reverted changes.

When a PR has been reverted, you might see a pair of updates in the PR that look like the following example, which shows the commit that reverted the PR and the issue that reintroduced the changes:

finding revert 2

In some cases, you can follow a chain of revert PRs and reintroduce issues until you find a commit in a PR that was successfully merged. In the PR that was reverted, click the link for Reintroduce change reverted from nnnn and repeat the procedure that was described previously, working from the issue that reintroduced the change.

However, this method depends on developers properly associating the PRs that reintroduce the updates to the reintroduce issue. If this doesn’t happen, you can end up with the appearance that the issue was never remerged, when in fact it was.

If you follow the revert and reintroduce chain and it results in success, you can count on the results. However, if you encounter a dead-end, the issue might or might not be resolved. In those cases, you might need to do more digging or contact support to determine when or if the fix was delivered.