fix: let one job require be join

[y-oksaku]

Context

When the following settings are made, the join job does not run upon restarting the build from main. This is due to the fact that when a Remote Join is composed of only one job, it is not treated as a Remote Join and it is also not triggered as ~sd@456:sub.

# upstream pipeline(id:123)
jobs:
  main:
    requires: [ ~commit ]
  join:
    requires: [ sd@456:sub ]

# downstream pipeline(id:456)
jobs:
  sub:
    requires: [ ~sd@123:main ]

Objective

This PR will make a correction to treat it as a join condition even if it consists of only one job.
Once it is treated as a Remote Join, it will no longer be excluded at the part below during restart, allowing the build to run correctly.

https://github.com/screwdriver-cd/screwdriver/blob/c1f15b7647dc4360093e9df64d9db69131718640/plugins/builds/index.js#L1009

References

License

I confirm that this contribution is made under the terms of the license found in the root directory of this repository's source tree and that I have the authority necessary to make this contribution on behalf of its copyright owner.

[y-oksaku]

The essence of this PR is here.

- const isJoin = upstreamAnd.size > 1;
+ const isJoin = upstreamAnd.size >= 1;

[jithine]

For a single job in requires, do we treat it as a join, or just a regular external trigger ? Is this PR addressing the scenario where ~ in requires doesn't matter if it's a single job in requires?

[tkyi]

Small suggestions

[y-oksaku]

For a single job in requires, do we treat it as a join, or just a regular external trigger ?

Yes. We treat it as join case.
So, requires: [ ~sd@123:main ] is a regular external trigger, but requires: [ sd@123:main ] is a join.

Is this PR addressing the scenario where ~ in requires doesn't matter if it's a single job in requires?

I think YES.

Currently, requires [ ~sd@123:mian ] is triggered by here in commit build.
And it is triggered by here ~ eventFactory in restart build.

On the other hands, requires [ sd@123:mian ] is triggered same as requires [ ~sd@123:mian ] case in commit build, but it is not triggered in restart build.
If we treat single join case as join, then it will be triggered same as commit build case too.

[sd-buildbot]

🎉 This PR is included in version 4.1.1 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀

[jithine]

@y-oksaku this is causing some undesirable behavior when 2 pipelines has multiple single job triggers against each other. We would work an a sample workflow and share further details

[jithine]

So what's happening is that prior to this change, something like this

    Y2:
        requires: [~sd@12753:B, trigger]

would have triggered job Y2, on completion of build for job sd@12753:B because ~ implied OR join
But now Y2 won't be triggered, because instead of OR semantics for ~sd@12753:B, it is treated as sd@12753:B which does AND of sd@12753:B and trigger

Ref:

1. https://github.com/adong/sd-remote-join-p2/blob/main/screwdriver.yaml#L21
2. https://cd.screwdriver.cd/pipelines/12753/events/780714
3. https://cd.screwdriver.cd/pipelines/12754/events/780716

cc @y-oksaku @kumada626

[y-oksaku]

So what's happening is that prior to this change, something like this

    Y2:
        requires: [~sd@12753:B, trigger]

would have triggered job Y2, on completion of build for job sd@12753:B because ~ implied OR join But now Y2 won't be triggered, because instead of OR semantics for ~sd@12753:B, it is treated as sd@12753:B which does AND of sd@12753:B and trigger

Ref:

1. https://github.com/adong/sd-remote-join-p2/blob/main/screwdriver.yaml#L21
2. https://cd.screwdriver.cd/pipelines/12753/events/780714
3. https://cd.screwdriver.cd/pipelines/12754/events/780716

@jithine
This issue has occurred in a previous API version as well, for example, it arises in cases where there are two join jobs, such as the following.
The absence of processing for the OR trigger in the remote trigger is the cause.

jobs:
  hub:
    requires: [ ~commit, ~pr ]
  test:
    requires: []
  test2:
    requires: []
  Y2:
    requires: [ ~sd@10:foo, test, test2 ]

However, with this PR, since a job is now treated as a join even when there is only one, the situation described in the comment has occurred.