Jitpack: custom domain for organization

[DadiBit]

📋 Description

Jitpack.io allows custom domains to be used, but shields.io allows only VCS ones.
It would be nice to add a "custom" or "organization" endpoint to use them (eg: https://img.shields.io/jitpack/v/custom/com.open-meteo/open-meteo-api-kotlin.svg).

[chris48s]

This sounds like a reasonable request. Just to flesh out how this would work a bit..

At the moment, if you request https://img.shields.io/jitpack/v/github/jitpack/maven-simple then we call https://jitpack.io/api/builds/com.github.jitpack/maven-simple/latestOk to get the version.

How would your example translate to a JitPack API call?

[DadiBit]

How would your example translate to a JitPack API call?

You may replace com.github.jitpack with the domain name reverse (io.jitpack); hence: https://jitpack.io/api/builds/io.jitpack/maven-simple/latestOk

[calebcartwright]

I feel like we've had some past discussions around just requesting the group id (or equivalent) as a free form route parameter instead of trying to do the version control to group id mapping, but my GitHub search skills are failing me. I would much rather we not be in the business of trying to support auto mappings

[chris48s]

Yeah it would be nice if we could change this so that the canonical jitpack badge URLs become:

• /jitpack/v/com.github.jitpack/maven-simple
• /jitpack/v/com.open-meteo/open-meteo-api-kotlin

and then set up redirects so that a request to /jitpack/v/github/jitpack/maven-simple redirects to /jitpack/v/com.github.jitpack/maven-simple. I think the existing redirect we have on this probably prevents us from doing that though: https://github.com/badges/shields/blob/master/services/jitpack/jitpack-version-redirector.service.js . Any other ideas on how we could restructure it?

[DadiBit]

I think the existing redirect we have on this probably prevents us from doing that though: https://github.com/badges/shields/blob/master/services/jitpack/jitpack-version-redirector.service.js . Any other ideas on how we could restructure it?

@chris48s I can only think of these possible solutions (I wrote some pseudo-code, it might help):

Not-at-all safe

Ditch the /jitpack/v/${user}/${repo} redirect to /jitpack/v/github/${user}/${repo} (terrible idea, imho, as it breaks old badges)

Safest

Implement a new /jitpack/v/any/${group}/${artifact} (or /jitpack/v/custom/${group}/${artifact}?) endpoint

1. Redirect /jitpack/v/${user}/${repo} to /jitpack/v/any/com.github.${user}/${repo}
2. Redirect /jitpack/v/${vcs}/${user}/${repo} to /jitpack/v/any/com.${vcs}.${user}/${repo}
3. /jitpack/v/any/${group}/${artifact} gets data from https://jitpack.io/api/builds/${group}/${artifact}/latestOk

Nicest

Use /jitpack/v/${group}/${artifact}. After the artifact a /{repo} block may be present (see points 1. and 4.)

1. Does ${group} match github|bitbucket|gitlab|gitee? If so it's a "new-ish" request: redirect to /jitpack/v/com.${group}.${artifact}/${repo} (group is a vcs, artifact is a user name)
2. Does ${group} start with com.${vcs} (with regex /^com.(github|bitbucket|gitlab|gitee)/.test(group))? If so skip to 5.
3. Reverse the ${group} to get a ${domain} (like .split('.').reverse().join('.'); com.domain.sub becomes sub.domain.com)
4. Does git.${domain} DNS redirect to a github repo (no idea how to check this like dig txt)? If not, try as last resort the old /jitpack/v/${user}/${repo} (hence redirect to /jitpack/v/com.github.${group}/${artifact}
5. Perform the query to https://jitpack.io/api/builds/${group}/${artifact}/latestOk

Please note that points 3. and 4. might not be required, as it's unlikely that a github user has a domain starting with a TLD (it may even be disallowed, as github.com/com.google and similars lead to a blank page; no information about that in the username policies 😶).

[chris48s]

Its all fun games until someone turns up and says "my github username is com.bitbucket.steve"

I think I'm inclined to go with some variation of the 'safe' option. Another variation of that we could do is switch from /jitpack/v to /jitpack/version. It breaks with convention but gives us a 'clean start'. That might be the least worst option.

[DadiBit]

Its all fun games until someone turns up and says "my github username is com.bitbucket.steve"

I was thinking the same, so I decided to just test it, and the signup page throws the following error:

Username may only contain alphanumeric characters or single hyphens, and cannot begin or end with a hyphen.

We can safely assume that usernames with dots are not allowed to be registered. With that said, I had found some old issues that talked about usernames with dots: probably GitHub disallowed them somewhere in the past, but I didn't find any reference of when it happened, but most importantly if GitHub forced users to change username or simply disabled new ones from signing up with them.

I think I'm inclined to go with some variation of the 'safe' option. Another variation of that we could do is switch from /jitpack/v to /jitpack/version. It breaks with convention but gives us a 'clean start'. That might be the least worst option.

Yep, and it would also mean less risky redirects (no infinite redirect loops or similar bugs)

[DadiBit]

I have never worked with Angular, so I would prefer if someone else could test this code (I coded a lot with JavaScript, so I know the language itself, but I have never used/setup Angular).
The jitpack-version-redirector.service would become:

export default [
  redirector({
    category: 'version',
    route: {
      base: 'jitpack/v',
      pattern: ':groupId/:artifactId',
    },
    transformPath: ({ groupId, artifactId }) =>
      `/jitpack/version/com.github.${groupId}/${artifactId}`, // this change is recommended (-1 redirect)
    dateAdded: new Date('2022-08-21'),
  }),
  redirector({
    category: 'version',
    route: {
      base: 'jitpack/v',
      pattern: ':vcs(github|bitbucket|gitlab|gitee)/:user/:repo',
    },
    transformPath: ({ vcs, user, repo }) =>
      `/jitpack/version/com.${vcs}.${user}/${repo}`,
    dateAdded: new Date('2022-08-21'),
  }),
]

And the service would become:

// ...
  static route = {
    base: 'jitpack/version',
    pattern: ':groupId/:artifactId'
  }

  static examples = [
    {
      title: 'JitPack',
      namedParams: {
        groupId: 'github',
        artifactId: 'maven-simple',
      },
      staticPreview: renderVersionBadge({ version: 'v1.1' }),
      keywords: ['java', 'maven'],
    },
  ]

  static defaultBadgeData = { label: 'jitpack' }

  async fetch({ groupId, artifactId }) {
    const url = `https://jitpack.io/api/builds/${groupId}/${artifactId}/latestOk`

    return this._requestJson({
      schema,
      url,
      errorMessages: { 401: 'project not found or private' },
    })
  }

  async handle({ groupId, artifactId }) {
    const { version } = await this.fetch({ groupId, artifactId })
    return renderVersionBadge({ version })
  }
}

[chris48s]

That looks roughly right to me - certainly a solid basis for a PR. It will be easier to test and review if you submit a PR.

The one thing I'd pick out is in your example, I think groupId: 'github', should be groupId: 'com.github',

Btw, where have you got angular from? We don't use angular in shields, so fortunately that won't be a barrier :)

[DadiBit]

That looks roughly right to me - certainly a solid basis for a PR. It will be easier to test and review if you submit a PR.

I'll fork the project and make a pull request 👍

The one thing I'd pick out is in your example, I think groupId: 'github', should be groupId: 'com.github',

Yep, I forgot that I needed to change from the old vcs value to the full groupId: 'com.github.jitpack'. Thank you!

Btw, where have you got angular from? We don't use angular in shields, so fortunately that won't be a barrier :)

Oops, VS code automatically showed the Angular icon, because the file names matches *.service.js lol