Re-test a project if one or more of its dependencies is updated

Using Jenkins
1
  1. I have not use Jenkins before
  2. I’m hoping to migrate my CD to Jenkins if it meets criteria
  3. Specifically, I’m working on PHP projects with composer
  4. Is it possible for setup Jenkins so that when a dependent composer package is updated, Jenkins will re-test the affected projects and subsequently deploy the projects if all tests passes?
2025: The Year in Review
2

You should have some manifest file for it so you are going to do a pull request or a change on the same repo or you have multiple repo? Anyway both are possible to Jenkins. Please give an example concrete like hello world

3

Are you familar with PHP and composer?

  • composer.json
    {
    "name": "bilogic/my-project-1",
    "require": {
        "bilogic/enum": "^3.13"
    }
}
  1. If bilogic/enum made a release and is updated to 3.14, I assume Jenkins gets “informed” since I’m using it to do my CD
  2. After Jenkins is aware, it needs to re-test bilogic/my-project-1 and any other project that depends on bilogic/enum
  3. My questions are: how do I configure Jenkins to do 1 and 2?

I’m aware of GitHub - dependabot/example-cli-usage: Demonstrates how to self-host Dependabot :dependabot:, but it is poll driven rather than push driven. I want my projects to re-test immediately to keep the feedback loop tight.

4

Yes the idea is to use a product right renovate or dependabot that generate a pull request or a patch set and automatic trigger a build. Alternative you need to let your project Jenkins know what package it depends on and have a trigger for each, find new tag created for them and sed your json but this is not easy to maintain and stupid. You don’t need to track dependency because I hope this done by packet manager. If you do the last way then you should have a patch from it so make no sense. I think you should just configure dependabot or renovate

5
  1. It’s hard to crystalize what you are trying to say.
  2. Are you saying Jenkins cannot be configured to do what I want?
  3. Are you also saying that renovate/dependabot can be configured to push?
6

Usually dependabot and renovate open PRs in your repo when they detect that a version you depend on has changed and you can configure them how often they look for changes.
Github (gitlab and others as well) can send push notifications to your Jenkins when a PR is opened or updated.

7

Well what you describe is dependabot/renovate polling bilogic/enum to see if has been updated. Too inefficient that’s why it is normally once a day, thus too slow.

So, while I could execute a webhook when bilogic/enum has a new tag, which Jenkins API URL understands the webhook and can figure out bilogic/my-project-1 needs to be re-tested?

8

Why you don’t use composer update of you php dependencies and using a polling method? composer update look for any update dependency. You can have a job that schediling every minute, run a composer update and if anything change run a build. Why you need to monitor?

9

Answers to your questions are in my previous replies.

10

Am I right that you control both bilogic/enum and bilogic/my-project-1? Then when both a are built with Jenkins you can just trigger a build of the latter after bilogic/enum was built and published passing the new version. The you modify the composer.json (I’m not familiar with php so don’t really know if that is necessary) and run the builds and tests. You can also integrate that the updated composer.json is pushed to git. Jenkins is very flexible

11

There are many projects, and many packages. Each project uses different packages depending on requirements. And the only place that tracks which project is using which packages is the composer.json of the project.

  1. Yes, I control both repositories
  2. But what I’m trying to say is: I don’t build projects and packages together.
  3. In fact, composer and PHP has no concept of build, I would not count composer update as build
  4. I modify a package based on new requirements and try my best not to break anything (verified by the package’s test)
  5. The re-testing of a project is to confirm that I indeed, did not break anything
  6. So far, I’m still not hearing any push solution
12

Who executes the push?
You can write your own plugin that is able to receive push events and then trigger the jobs you want.

13

I git push to a Gitea repository, that’s all. Gitea can fire webhooks to anywhere. I was hoping Jenkins had a way to take care of this already.

14

The Gitea plugin provides a Gitea branch source that will automatically create and delete jobs based on branches and pull requests. That is described in the Jenkins documentation as a multibranch Pipeline.

An even higher level concept is available that will monitor for the creation and deletion of repositories using a Gitea organization folder.

The Gitea branch source will manage the webhooks for you. The docs say:

Optionally enable the “manage hooks” checkbox, this will allow Jenkins to configure your webhooks using an account of your choosing.

15

Your flow is not clear to me:

You have one project with its own composer.json
then you have a library used by this project having its own composer.json

What do you push? I mean a change in composer.json, you don’t want to push anything and wait that jenkins build because anything package inside the composer.json has a new version? Describe your flow in a concrete way.

16

The questions you ask tells me you are not familiar how composer’s flow, it’s better to ask clarifying questions instead of saying it is not concrete, I do not know what you do not understand.

In brief, I will describe using git terms:

  1. Every composer project/package aka repository has its own composer.json, in this context, the important bit is the requires field which states which other repositories and their semver this repository needs in order to run correctly
  2. New bilogic/enum code is only released to the public when the git commit is tagged
  3. Thus, when I git push, the test action will run and if it passes, this commit will be tagged
  4. This is when bilogic/enum will webhook someone (Jenkins) about its new tag
  5. Since the news is out, how does this someone (Jenkins) figure out that there is a project named bilogic/project-1 that requires bilogic/enum? And proceed to re-test it

Now, which point are you unable to follow?

17

I tried reading the docs, but I’m unable to see a link between multibranch pipeline and figuring out the bilogic/project-1 needs to be re-tested.

18

Yes, composer.json can get any other dependencies that are not controlled by you for example some other package is not in the gitea. If your problem is just to trigger a pipeline when anyone of them in gitea has a pull request, that is not a problem to get in jenkins. You need only to define the trigger needed (for each project you are monitoring) and you can have one pipeline for them. I’m using Jenkins MultiBranch Pipeline and Remote Jenkinsfile Provider . This was the reason I mention dependabot or renovate. BTW I can imagine that can be done in some other way too.

This is an example of a iot firmware

```

properties {
    pipelineTriggers {
        triggers {
            gerrit {
                serverName('Amarula Solutions Gerrit')
                triggerOnEvents {
                    patchsetCreated {
                        excludeDrafts(true)
                        excludeWipState(true)
                    }
                }
                gerritProjects {
                    gerritProject {
                        compareType('ANT')
                        pattern('duckacme/build')
                        branches {
                            branch {
                                compareType('ANT')
                                pattern('**')
                            }
                        }
                        disableStrictForbiddenFileVerification(false)
                    }
                    gerritProject {
                        compareType('ANT')
                        pattern('duckacme/firmware')
                        branches {
                            branch {
                                compareType('ANT')
                                pattern('**')
                            }
                        }
                        disableStrictForbiddenFileVerification(false)
                    }
                    gerritProject {
                        compareType('ANT')
                        pattern('duckacme/manifest')
                        branches {
                            branch {
                                compareType('ANT')
                                pattern('**')
                            }
                        }
                        disableStrictForbiddenFileVerification(false)
                    }
                }
            }
        }
    }
}

```

This define a set of trigger for each repo that I want to monitor. This does not scale if you are not define your relation somehow.

19

When you test your package, that is done based on the sources right? So I would assume that when you want to run tests based on the new version that you have to modify the composer.json before you start the tests.
I don’t think that there is plugin for your specific use case.
So here’s a rough sketch what a plugin would need to do.
In order for Jenkins to know which projects to build it would need to know which projects have a dependency defined in their composer.json. So projects for which that should happen must be flagged in a way (property) to avoid that Jenkins runs that for each project.
Then Jenkins would need to read that file in some way (the file is likely not available in the file system on the controller, so it would need to make a request to the scm and get it from there), then it needs to parse the file and when the changed dependency is there it can trigger a new run for the project.

20

There is no need to modify composer.json of the project, it conforms to semver, ^12 means I use anything that starts with 12, does this make sense?

In any case, I thank everyone for the responses.

I would think my request was a basic one, assuming we always want our projects to be using the latest, yet compatible versions of our libraries because of security.

Dependabot’s once a day check is too slow for development. By the time the project(s) break, it becomes harder to figure out which commit is the culprit. Setting it to check every min is also not something a modern CI/CD should be doing.

I will be sticking to my current CD that works as I described, the only trouble is maintenance and lack of widespread use, thus I’m not assured of its security.