Updates being proposed from repositories defined only in optional profiles

[jglick]

Is there an existing issue for this?

• I have searched the existing issues

Package ecosystem

Maven

Package manager version

No response

Language version

No response

Manifest location and content before the Dependabot update

No response

dependabot.yml content

For example

version: 2
updates:
- package-ecosystem: maven
  directory: "/"
  schedule:
    interval: weekly
  open-pull-requests-limit: 10

Updated dependency

No response

What you expected to see, versus what you actually saw

@jenkinsci has observed a recent change in Dependabot behavior which I suspect is due to #13747 and which is a serious regression tracked in jenkins-infra/helpdesk#4990: updates are being offered for a repository defined only in an optional profile which was never intended to be visible to Dependabot and which previously was not.

Initially I thought the problem was limited to a specific artifact, a parent POM, but I just saw the same behavior in a private repository inheriting the same profile but referring to an artifact used as a regular dependency.

Native package manager behavior

mvn versions:display-dependency-updates offers only versions coming from repositories which are actually active.

Images of the diff or a link to the PR, issue, or logs

No response

Smallest manifest that reproduces the issue

I can try to put together a minimal test case if that would be helpful in understanding the problem. Initially observed in a large batch of PRs such as jenkinsci/mailer-plugin#616. You will note that mvn validate fails now in the master branch of that repo.

[yeikel]

This issue is likely related to #13747 in that Dependabot now checks all the repositories, but I would not call that a regression directly (ie: we should not revert it) and more a discovery of a defect that was always there waiting to happen. At no time Dependabot ever considered disabled repositories

I assume that the fix here involves skipping any repository that is <enabled>false</enabled>.

@thavaahariharangit I see you assigned yourself to this, if you plan on fixing it please let me know, otherwise I'll send a fix today

[jglick]

I assume that the fix here involves skipping any repository that is <enabled>false</enabled>.

No, it is about repositories which were not defined at all. Something in DB is apparently looking into /project/profiles in addition to the main /project/repositories section.

(If the profile is enabled by default, fine, but in this case it is not.)

[jglick]

Perhaps

dependabot-core/maven/lib/dependabot/maven/file_parser/repositories_finder.rb

Line 25 in c18cade

REPOSITORY_SELECTOR = "repositories > repository, " \

is just looking for anything named <repositories> regardless of tree position?

[jglick]

This issue is likely related to #13747 in that Dependabot now checks all the repositories, but I would not call that a regression directly (ie: we should not revert it)

Even in the short term? #9383 was at least for the original reporter (in @jenkinsci) a minor issue pertaining to a corner case; whereas the new behavior is an ongoing emergency with no clear workaround.

[yeikel]

I assume that the fix here involves skipping any repository that is <enabled>false</enabled>.

No, it is about repositories which were not defined at all. Something in DB is apparently looking into /project/profiles in addition to the main /project/repositories section.

(If the profile is enabled by default, fine, but in this case it is not.)

Please help me understand this.

If a profile is defined as false (in the pom, not anywhere else such as the command line), would it help if we skip these repositories?

Dependabot does not run Maven, so it will not have all the context in advance to know if you conditionally enable/disable these profiles. However, we can do a best effort and read the pom file and decide if a repository should be excluded

This issue is likely related to #13747 in that Dependabot now checks all the repositories, but I would not call that a regression directly (ie: we should not revert it)

Even in the short term? #9383 was at least for the original reporter (in @jenkinsci) a minor issue pertaining to a corner case; whereas the new behavior is an ongoing emergency with no clear workaround.

If I cannot get a fix by EOD today, I'll revert. I'd rather not revert because it fixes a very valid need beyond that other defect

[jglick]

If a profile is defined as false

Well, it just does not request to be enabled. Obviously profile activation can be complex in general.

Let me see if I can put together a minimal reproducer…

[yeikel]

Let me see if I can put together a minimal reproducer…

Thank you. That would help me a lot to put the fix together + verify

[jglick]

Got something: jglick/dependabot-14148-demo#1

As you can see by https://github.com/jenkinsci/mock-slave-plugin/releases, 212 is not supposed to be considered at all. It is apparently being found from https://repo.jenkins-ci.org/artifactory/incrementals/org/jenkins-ci/plugins/mock-slave/ (but not 213 or 214? for some reason?) whereas only https://repo.jenkins-ci.org/artifactory/public/org/jenkins-ci/plugins/mock-slave/ is expected to be consulted.

$ docker run -v --rm -v "$PWD":/src -w /src maven:3-eclipse-temurin-21 mvn -B -ntp versions:display-dependency-updates
[INFO] Scanning for projects...
[INFO] 
[INFO] -----------------------------< demo:demo >------------------------------
[INFO] Building demo 0-SNAPSHOT
[INFO]   from pom.xml
[INFO] --------------------------------[ pom ]---------------------------------
[INFO] 
[INFO] --- versions:2.21.0:display-dependency-updates (default-cli) @ demo ---
[INFO] The following dependencies in Dependencies have newer versions:
[INFO]   org.jenkins-ci.plugins:mock-slave ...
[INFO]                                 193.v88c279d0c584 -> 217.v67c790ca_a_c31
[INFO] 
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  8.720 s
[INFO] Finished at: 2026-02-10T19:09:07Z
[INFO] ------------------------------------------------------------------------

In this case adding -Pconsume-incrementals does not change the output since the proposed version is actually older than the latest release in the default repository:

  <versioning>
    <latest>217.v67c790ca_a_c31</latest>
    <release>217.v67c790ca_a_c31</release>

vs.

  <versioning>
    <latest>214.vce3cb_1d78777</latest>
    <release>214.vce3cb_1d78777</release>

[jglick]

Also try

$ docker run -v --rm -v "$PWD":/src -w /src maven:3-eclipse-temurin-21 mvn -B -ntp help:effective-pom -Doutput=/dev/stdout -q | xmlstarlet sel -N pom=http://maven.apache.org/POM/4.0.0 -t -v /pom:project/pom:repositories/pom:repository/pom:id -n
repo.jenkins-ci.org
central

compared to adding -Pconsume-incrementals.

[yeikel]

Thanks for the reproducer

if I understood correctly. Dependabot should not consider repositories from profiles unless they have activeProfiles set to true as Maven does not use profiles unless explicitly activated. For example, following your reproducer:

    <profiles>
        <profile>
            <activation>
                <activeByDefault>true</activeByDefault> <!--- This repo should be considered because Maven will -->
            </activation>
            <id>consume-incrementals</id>
            <repositories>
                <repository>
                    <id>incrementals</id>
                    <url>https://repo.jenkins-ci.org/incrementals/</url>
                </repository>
            </repositories>
        </profile>
        <profile>
            <activation>
                <activeByDefault>false</activeByDefault> <!--- This repo should not be considered because it is disabled -->
            </activation>
            <id>Another profile</id>
            <repositories>
                <repository>
                    <id>incrementals</id>
                    <url>https://repo.jenkins-ci.org/some other repo/</url>
                </repository>
            </repositories>
        </profile>
    </profiles>

[jglick]

Yes <activeByDefault>true</activeByDefault> would imply that it makes sense to search that repo. I am sure you can find some project which would prefer a different logic but that is probably true of any design choice in Dependabot…