Latest release page does not have clickable github release links

[sxa]

On https://adoptopenjdk.net/archive.html the release names in the squares on the left of the page are clickable and take you to the coirresponding github release, but in the "Latest release" page at https://adoptopenjdk.net/releases.html they are no such links.

[akdsco]

I looked into this, and it seems like the problem could be in data being lost somehow when it's manipulated in JS file. However, the problem I encountered was that any time I made a small change in JS file, like console.log(), after gulp rebuilds the files, it comes back with this error message:

GET http://localhost:3000/dist/js/app.min-77d542e9.js net::ERR_ABORTED 404 (Not Found)

Since I've never worked with your repo yet, I thought it might be worth asking if there is something you've set up explicitly with JS processing and I have to first "switch" to work with local files and be able to change their values?

[ParkerM]

I looked into this, and it seems like the problem could be in data being lost somehow when it's manipulated in JS file.

It sounds like you're on the right track, but I think it may be related to how the API endpoints differ between each page.

It looks like the Archive page is pulling data from /assets/feature_releases/:version/:release_type, which contains a release_link attribute along with a list of binary resources for each release:

API response from the Archive page example (Huge JSON warning)

---

Whereas the Latest Releases page is hitting /assets/latest/:version/:jvm_impl, which just returns a list of binary resources without the top-level release attributes:

API response from the Latest Release page example

---

However, the problem I encountered was that any time I made a small change in JS file, like console.log(), after gulp rebuilds the files, it comes back with this error message:

GET http://localhost:3000/dist/js/app.min-77d542e9.js net::ERR_ABORTED 404 (Not Found)

That issue sounds oddly familiar, I think I ran into something similar before when I was using an incompatible version of node. It looks version 10 is the one currently used in Travis CI, and switching to version 10 with nvm seems to work OK on my workstation. Also make sure you're using the instructions from CONTRIBUTING.md to configure/run the continuous build. (idk if that could cause a problem or not but just in case.)

[akdsco]

Wow, @ParkerM what a great response 👍 Thank you

Ok, it looks like it is the case with the API response being different.
Now, I believe that we have two options here:

1. we change the way API responses (so that it gives us release_link)
   or
2. we fetch from a different url and get the data we want this way

I explored this API's structure page but only found a couple of example queries. Maybe there is a better way to query API and get the relevant release_link with each record, but I couldn't find one. Made me think that it would be great if docs about the API would be more extensive.

Do you think there's a way to try and change the API's response and get it done this way?

PS. I ended up reinstalling my os and installing node using nvm from the start, this helped with the error I was getting. Thanks!

[ParkerM]

Now, I believe that we have two options here:

1. we change the way API responses (so that it gives us release_link)
   or

2. we fetch from a different url and get the data we want this way

Agreed that those sound like the two most valid options.

I'm inclined to say that the first one seems like the most sensible approach. Namely because both of those API endpoints return a release_name attribute, but release_link is only missing from one of them, so presumably they're both querying that same Release resource but only one of them is currently including release_link in its response.

Alternatively, the second approach could work by grabbing the version string from the version.semver property of one of the objects returned in first response, then use that in a subsequent call to /assets/version/:version and grabbing the release_link from there.
E.g.,

GET /v3/assets/latest/11/:jvm_impl

[
  {
    "binary": {},
    "version": {
      "semver": "11.0.8+10"
    }
  },
]

GET /v3/assets/version/11.0.8+10?jvm_impl=:jvm_impl&page_size=1

[
  {
    "binaries": [],
    "release_link": "https://github.com/AdoptOpenJDK/openjdk11-binaries/releases/tag/jdk-11.0.8%2B10",
    "version_data": {}
  }
]

It'd be less than ideal to have to make a second request just for the release link, and it'd kind of misappropriate that particular API, but that's one idea. There may be a more lightweight API that could accomplish the same thing.

---

One thing's kinda funky about the GitHub release links as they pertain to this issue, and is likely the reason that release_link was added to one API but not the other:
The Archive page shows many different release "panes" that each represent many binary artifacts and their corresponding GitHub release link. However, the Latest Release page shows a single release split out into many release "panes" for each OS/Arch. So each pane on the Latest Release page would have the same GitHub release link.

That may be counterintuitive from a UX perspective since the Latest Release "panes" are grouped by OS/Arch, implying that a link in one pane would point to something specific to that OS/Arch when really they all point to the same place. I'm probably nitpicking but figured I should bring it up (@sxa may have additional thoughts).

---

I explored this API's structure page but only found a couple of example queries. Maybe there is a better way to query API and get the relevant release_link with each record, but I couldn't find one. Made me think that it would be great if docs about the API would be more extensive.

You might have better luck with the Swagger UI. It'll show all the available endpoints and schema definitions for the resources returned by each.

[gdams]

Closing in favour of adoptium/adoptium.net#117