[WIP] Added FreeBSD Port version shield

[ruudboon]

Added FeeBSD shield, see #1693
Would like to add some tests but don't have a clue how simulate a non json request.

[shields-ci]

	Warnings
⚠️	This PR modified service code for freebsd but not its test code. That's okay so long as it's refactoring existing code.

	Messages
📖	✨ Thanks for your contribution to Shields, @ruudboon!

Generated by 🚫 dangerJS against b888e7c

[lgtm-com]

This pull request introduces 1 alert when merging 505e42c into 347e0a8 - view on LGTM.com

new alerts:

• 1 for Useless assignment to local variable

[0mp]

You may try to parse information available at https://www.freshports.org/ instead of the raw makefiles from the GitHub mirror.

[ruudboon]

@0mp I tried but wasn't able to find a proper solution to detect the latest version and the page is pretty heavy to parse (319KB)

[ruudboon]

@0mp Maybe we can do something like this: FreshPorts/freshports#132 ;)

[calebcartwright]

Thanks for the PR @ruudboon! Could someone please articulate why repology/other upstream data sources are insufficient?

We can certainly fallback to parsing raw files downloaded from GitHub if neccessary, but would always prefer to get data from an upstream API/endpoint.

Also as a heads up, if indeed the only viable approach is the raw files, then this PR will need to be refactored to follow our standard model for GitHub interactions (to deal with GH's auth, rate limiting, etc.). Will provide more details on those changes if/when needed.

[ruudboon]

@calebcartwright I didn't find an other way to retrieve this information. I prefer an api as well.
Looks like Freshports hold these kind of information but currently only on a full large html page.
I dropped a pull there to see if we can do something different that looks like an api.

[calebcartwright]

With the repology API, using the project as the first param we can get a JSON response. Could that not be used (with various Shields route param for repo, category, etc.) to retrieve the version?

https://repology.org/api/v1/project/php:phalcon4

[
  {
    "repo": "freebsd",
    "srcname": "www/phalcon4",
    "binname": "php72-phalcon4",
    "visiblename": "www/phalcon4",
    "version": "4.0.0",
    "maintainers": [
      "franco@opnsense.org"
    ],
    "www": [
      "https://phalcon.io/"
    ],
    "summary": "Phalcon PHP Framework written in C-language",
    "categories": [
      "www"
    ],
    "status": "newest",
    "origversion": null
  },
  {
    "repo": "freebsd",
    "srcname": "www/phalcon4",
    "binname": "php73-phalcon4",
    "visiblename": "www/phalcon4",
    "version": "4.0.0",
    "maintainers": [
      "franco@opnsense.org"
    ],
    "www": [
      "https://phalcon.io/"
    ],
    "summary": "Phalcon PHP Framework written in C-language",
    "categories": [
      "www"
    ],
    "status": "newest",
    "origversion": null
  },
  {
    "repo": "freebsd",
    "srcname": "www/phalcon4",
    "binname": "php74-phalcon4",
    "visiblename": "www/phalcon4",
    "version": "4.0.0",
    "maintainers": [
      "franco@opnsense.org"
    ],
    "www": [
      "https://phalcon.io/"
    ],
    "summary": "Phalcon PHP Framework written in C-language",
    "categories": [
      "www"
    ],
    "status": "newest",
    "origversion": null
  },
  {
    "repo": "dports",
    "srcname": "www/phalcon4",
    "binname": "php72-phalcon4",
    "visiblename": "www/phalcon4",
    "version": "4.0.0.r.3",
    "maintainers": [
      "franco@opnsense.org"
    ],
    "www": [
      "https://phalcon.io/"
    ],
    "summary": "Phalcon PHP Framework written in C-language",
    "categories": [
      "www"
    ],
    "status": "outdated",
    "origversion": null
  },
  {
    "repo": "dports",
    "srcname": "www/phalcon4",
    "binname": "php73-phalcon4",
    "visiblename": "www/phalcon4",
    "version": "4.0.0.r.3",
    "maintainers": [
      "franco@opnsense.org"
    ],
    "www": [
      "https://phalcon.io/"
    ],
    "summary": "Phalcon PHP Framework written in C-language",
    "categories": [
      "www"
    ],
    "status": "outdated",
    "origversion": null
  },
  {
    "repo": "macports",
    "name": "php-phalcon4",
    "visiblename": "php-phalcon4",
    "version": "4.0.0-rc3",
    "maintainers": [
      "ryandesign@macports",
      "ryandesign@github"
    ],
    "licenses": [
      "BSD"
    ],
    "www": [
      "https://phalconphp.com/"
    ],
    "summary": "full stack PHP framework written as an extension",
    "categories": [
      "php"
    ],
    "status": "outdated",
    "origversion": "4.0.0-rc.3"
  },
  {
    "repo": "macports",
    "name": "php72-phalcon4",
    "visiblename": "php72-phalcon4",
    "version": "4.0.0-rc3",
    "maintainers": [
      "ryandesign@macports",
      "ryandesign@github"
    ],
    "licenses": [
      "BSD"
    ],
    "www": [
      "https://phalconphp.com/"
    ],
    "summary": "full stack PHP framework written as an extension",
    "categories": [
      "php"
    ],
    "status": "outdated",
    "origversion": "4.0.0-rc.3"
  },
  {
    "repo": "macports",
    "name": "php73-phalcon4",
    "visiblename": "php73-phalcon4",
    "version": "4.0.0-rc3",
    "maintainers": [
      "ryandesign@macports",
      "ryandesign@github"
    ],
    "licenses": [
      "BSD"
    ],
    "www": [
      "https://phalconphp.com/"
    ],
    "summary": "full stack PHP framework written as an extension",
    "categories": [
      "php"
    ],
    "status": "outdated",
    "origversion": "4.0.0-rc.3"
  }
]

[ruudboon]

I think repology is a bit to general to fetch a specific freebsd port. It combines packages. Phalcon4 works but if you use for example apache you can’t pinpoint the port. https://repology.org/api/v1/project/apache

Freshport replied in the meantime. Maybe we can work something out there. Does badges do any caching or is every svg request triggering an api call on the upstream?

[calebcartwright]

I think repology is a bit to general to fetch a specific freebsd port. It combines packages. Phalcon4 works but if you use for example apache you can’t pinpoint the port.

I think that would be the rationale then for a non-repology approach 👍

Does badges do any caching or is every svg request triggering an api call on the upstream?

There's multiple layers of caching between users requesting a badge and the upstream data providers (browsers, GH camo, our CDN, etc.) so each individual badge definitely does not result in an API hit directly on the upstream provider. We use different cache lengths for different types of badges (for example the cache length for licenses badges are much longer than build status badges, as the latter change way more frequently).

However, our badge servers don't currently cache any raw API responses from the upstream providers if that's what you're asking

[ruudboon]

@calebcartwright thnx for the explanation! Can we leave this pull open for a few days? I will update it when we have a new method to fetch the version from Freshports.

[PyvesB]

Any news on this pull request @ruudboon? Would be nice to get it landed! :)

[PyvesB]

Given that there hasn't been any activity for a while, I'm going to close this pull request. Feel free to reopen it if you get a chance to look into it again.

If someone else wants to pick this up, you can simply fetch the commits by running git fetch origin pull/4496/head:pr-4496. Address the pending review comments and open a new pull request with a co-authored trailer included in the commit message to give attribution to the original author.