Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Allow to run a satis build for one repo/package #125
Added an additional flag to generate the satis build for a single package. This helps to speed up the satis run if you have to deal with a lot of repos. In our case Jenkins will trigger the satis build after a new release was created. Since we have a lot packages (with a lot of versions) in our local satis repo, I was looking for a way to speed up the satis run.
added a commit
this pull request
May 1, 2014
referenced this pull request
May 9, 2014
I've been playing with this and was hoping that a such a single-package build would only fetch and re-scan the vcs repository for the given package.
In fact, the console output shows that satis iterates over all repositories again.
Am I missing anything or did I get this feature wrong?
BuildCommand::selectPackages() will as a first step do
... which will pull and re-scan all defined VcsRepositories even before the filter is applied.
Well no, you didnt get it wrong. But it kinda only solved half the problem - the actual package fetching.
TMK you can't select a repo based on package. The information just isn't available. You can only ask if the repo contains a specific package, wich potentially scans all repos to find one specific package.
I guess you could store which repo the package came from (in packages.json or somewhere else), and read from that. But in theory a package can change repo (and maybe even be split across multiple repos in different versions?). So a full scan is the only way to be sure you get all versions of the package.
Of course it could fall back to a full scan, if it can no longer find the package in the last repo it got it from. That would be fairly safe, and very rarely result in a full scan. But it would possibly create some edge cases where new versions wouldn't be found, for instance if the package moved repo, but didnt get removed from the old one.
Ok, trying to get this straight...
This PR allows to update selectively by providing a package name. It will then re-scan all configured repositories, figure out which versions of the package(s) are available in all of them and then dumpDownload() only versions of this package.
In contrary, PR #110 together with jkufner/satis#1 takes a repo URL as parameter and only re-scans this given repo for available packages. It then merges that information with the full set of packages which is kept serialized in a cache.
What I am aiming for are quick updates by mean of a webhook, as in #40. The URL-based "scan only one repo"-approach seems more fit here.
Looking at the code more closely:
So - wouldn't it be easier to apply the filtering in dumpDownloads only? That would make a much simpler implementation of the same behaviour IMO.