-
-
Notifications
You must be signed in to change notification settings - Fork 3.6k
Move away from Jitpack #12463
Copy link
Copy link
Open
Labels
dependencyIssues and PRs related to dependenciesIssues and PRs related to dependenciesdiscussionThis needs to be discussed before anything is doneThis needs to be discussed before anything is donefeature requestIssue is related to a feature in the appIssue is related to a feature in the app
Metadata
Metadata
Assignees
Labels
dependencyIssues and PRs related to dependenciesIssues and PRs related to dependenciesdiscussionThis needs to be discussed before anything is doneThis needs to be discussed before anything is donefeature requestIssue is related to a feature in the appIssue is related to a feature in the app
Checklist
Feature description
Following on from discussion in Matrix chat, we need to replace Jitpack with something else that has the same functionality.
As explained in this article, Jitpack is barely maintained, obtuse, fragile, can break any time, and is potentially a huge security breach waiting to happen.
I am making this issue for us to decide on the best replacement.
@Stypox suggested using an manual implementation for getting builds directly from github in settings.gradle, which I think would be good.
My ideal solution would allow us to specify getting builds for a specific commit hash, but also allow us to get the latest commit for a specific branch.
Builds for commits on main branches (dev, master, etc.) should have the jars/binaries be able to be downloaded from online similar to Jitpack (e.g. packages published via CI build upon merge to a main branch), but other branches can have the repo fetched and built locally.
Probably we publish release versions to Maven central, and intermediate versions for each commit can be published to Github Packages, and then can use manual retrieval in settings.gradle to get individual commits from forks/PRs/etc.
Why do you want this feature?
Explained already
Additional information
No response