On the “Build Information Repository” page, the filtering functionality doesn’t seem to work very well.
If I enter a partial or full package ID in the search box, I always get no results (seeing a query to https://octopus/api/Spaces-1/build-information?filter=myQuery&skip=0&take=50. If I change the URL to use the packageId parameter instead of filter it seems to work).
If I search for a package version, the response contains data, but the page doesn’t show any results.
If I click on a Package ID I expect the list to be filtered on that package id, but the page just reloads.
Thanks for reaching out to Octopus support.
Sorry to hear you’ve hit an issue.
I can’t seem to replicate the build information search issue, when I search for partial package IDs the correct build information is returned as expected.
May I ask which version of Octopus you’re using, please?
In regards to the API URL, the ?filter= parameter is to filter on version rather than packageid, if you use the ?packageid= parameter, you should be able to search using a partial name via API.
You can see this via https://octopusurl/swaggerui/index.json:
So you’re saying the search field is not supposed to let me filter/search on package id, but just versions? If so, I don’t think it’s very intuitive, and I wish it would let me filter on (partial) packageid as well.
I just noticed that the other issue I mentioned where clicking on a PackageId didn’t filter as I expected seems to only be a problem on PackageIds for my namespaced docker images, which contains a forward slash, like ns/myapp. The link points to https://octopusurl/app#/Spaces-1/library/buildinformation/versions/ns%2Fmyapp, but redirects back to https://octopusurl/app#/Spaces-1/library/buildinformation. For nuget-packages with periods it works as expected and I get a page filtered down to that packageid.
So I think this is the issue that is causing me the biggest headache, as it makes it very hard to find information about specific packages for my docker images when I can’t search for packageId, and I can’t get a page showing only versions for that packageId.
Also, another unexpected behavior i noticed is that when I open the build information page it only shows the highest version of my packages, with only one entry per packageId (which in my case gives 67 hits over two pages). But if I try to search for my packageId, realize it doesn’t work that way, and clear my search, the page lists all packages for every packageId (which seems to be caused by the filter-parameter being omitted, instead of being empty). In this case i get over 2000 hits, spread over 46 pages. This also feels like a bug.
Thanks for getting back to me and apologies, I may not have been clear in my wording.
When I mentioned that the filter parameter is designed to filter on version rather than package ID I meant the ?filter= parameter within an API request.
When done through the UI, the browser makes a request for all build information and is then sorted on the front-end based on queries made.
I wasn’t able to confirm an issue on latest in our cloud product but that may have been due to not having all the information on your build information.
It could be possible that a / in the package ID causes issues but we haven’t had any other reports of this.
That being said, I’m going to test it internally on your version to see if I can replicate the error you’re experiencing.
I’ll be in touch as soon as I have any further information for you.
I just wanted to let you know that I was able to reproduce this on your version and in latest.
The missing piece of the puzzle was requiring more than 50 records in the build information page.
The issue seems related to the “Load More” button, as if you click the button enough times to load the all build information records to one page, the search feature begins to work again.
This also feels like a bug.