-
Notifications
You must be signed in to change notification settings - Fork 515
-
Notifications
You must be signed in to change notification settings - Fork 515
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Specify/document how package selection switches (should) work together #184
Comments
@shochdoerfer What's the use case for the package filter (command line args) you implemented? Do you use it with Do you see any other useful way how it can be used? |
Without a package filter satis will build the packages for every known repo (as defined in the satis config file). This can lead to only waiting times when you deal with a lot of repos and a lot versions (as we do). When you pass a package or a list of packages to the build command only these packages get built (all repos still get queried but it is a lot faster in this case). This way when our Jenkins instance gets triggered for a specific project we can let satis build the packages for just that project which in our case is pretty fast. This was the main intention of the patch. Concerning the use of require-all or require in the config file I am not able to comment on that one. Maybe @akimsko can help out. If I recall correctly he contributed a patch on that matter. |
If I got you right, every time your Jenkins runs for a particular project it also runs Satis for this project's dependencies/packages. Do all these Jenkins runs share a single satis.json config file? Does that have a set of |
Oh. I have been looking at it from the package-selection perspective only. What I missed was that the existing |
Imaging we have two packages mycompany/package1 and mycompany/package2. Both reside in different git repos and are hooked into our Jenkins instance. Whenever I make a commit in either repo Jekins will run and do the usual stuff (phpcs, phpunit, ...). After the particular Jenkins job run successfully we need to let satis re-index the repo so that the latest changes are reflected in the satis repo (e.g. a new version of the package got released). In the past satis would run for every project on every commit which was very inefficient. Now with the package filtering in place satis will only build the package that needs to be built. We do only use one satis.json config file. I do not see that it would be possible to use multiple satis config files, one per project. That would probably mess things up I guess when it comes to generating the packages.json file. |
Correct, you need to take the generation of the package.json file into account. Someone recently lined out that the code seems to be too complex and could be simplified which might be true. Could not find the time so far to dig into that. The PR evolved over time as I got more and more insights into the inner workings of satis ;) |
Yes, I missed the fact that with the package filter enabled results will be merged into the existing packages.json. WIthout that merge, it would only output the packages you used for the filter, which in turn would not make sense if you change the filter on every run. So I thought that you would either use |
Good to hear and great to see that you tackle the "testing problem". In case of other questions concerning this PR feel free to ping me. |
Here is how I think the filter currently behaves:
Packages that are present in |
I updated the initial comment with an overview of how I think the switched should work together. I would really appreciate feedback especially from @naderman, @Seldaek and @stof to see if this is what you would expect as well. Seems the above description is not exactly what is currently happening for |
In order to write some tests for #180, I'd like to get an overview of the various package-selection-specific switches and how they go together (if at all).
In particular, we've got:
require-all
require
require-dependencies
require-dev-dependencies
minimum-stability
Additionally, the way
replace
is used (some bugs fixed recently) might come into play.Update
Here's how I think that the various switches should go together.
At all stages, packages not matching the
minimum-stability
will be discarded and their dependencies will not be followed.Step 1 – Initial package selection
require-all
true
false
require
list and version constraints.require
list that are given in the filter.Step 2 – Add/follow dependencies
require-dependencies
andrequire-dev-dependencies
is not set, nothing to do.Caveats
packages.json
. Also make sure we don't lose package versions not present in the update.provides
/replace
?The text was updated successfully, but these errors were encountered: