This PR moves the nightly-next CI to use the 6.3 images. Since those
checks should be non required on any user of this package and the name
of the check doesn't change with moving images this should be a
non-breaking change.
Generate matrix script finds manifests in subdirs
### Motivation:
The genereate matrix script attempts to derive the minimum Swift version
supported by the package so that it doesn't run CI on versions which are
older than that supported. At the moment it can't cope with repositories
with packages in subdirectories like swift-nio-examples.
### Modifications:
The script looks for manifests in subdirectories if
`FIND_SUBDIRECTORY_MANIFESTS_ENABLED=true`. This is opt-in because by
default CI only uses the top-level manifests.
### Result:
CI should generate more appropriate jobs.
An example of this in action
https://github.com/apple/swift-nio/actions/runs/18968739126/job/54171197381?pr=3431
Don't generate matrix jobs for Swift versions which aren't supported by
the package.
### Motivation:
Matrix workflows should not generate jobs for Swift versions < tools
version, doing so wastes compute and adds noise.
This means that:
- New repos don’t need to manually opt-out of old Swift versions
- Repos which have dropped an old Swift version (during a migration
window) won’t have failing tests until it’s turned off centrally.
### Modifications:
- The generate script now looks for `Package.swift` and
`Package@swift-*.swift` files and uses the lowest tools version in any
found file to determine the minimum supported Swift version
- Any Swift version lower than the minimum is disregarded and no jobs
are generated for it
- A new parameter is added to the workflows which allows the minimum
Swift version to be set manually (`minimum_swift_version`)
### Result:
By default in this and downstream packages we don't generate matrix jobs
for Swift versions which aren't supported by the package.
An example of this working:
https://github.com/apple/swift-nio/actions/runs/18711362977/job/53360387720?pr=3415
Allow the specification of custom environment variables in our matrix
workflow and those which use it.
### Motivation:
It can be useful to supply custom environment variables to control build
and runtime options.
### Modifications:
Allow users to supply a string of custom environment variable key-value
pairs which are supplied to the docker container running the matrix
commands.
To attempt to avoid issues with this string concatenation the change
also allows the user to specify custom list entry and key-value-pair
separators.
To avoid parameter bloat the env vars are set for all Swift versions,
hopefully that's sufficient for now.
### Result:
Adopters can
Examples of this working on Linux and Windows, note the presence of the
test environment variables I injected:
-
https://github.com/apple/swift-nio/actions/runs/17917619451/job/50943847555?pr=3376
- https://github.com/apple/swift-crypto/pull/413/checks
e.g.
```
Executing Docker command: docker run -v /home/runner/work/swift-nio/swift-nio:/swift-nio -w /swift-nio -e CI=true -e GITHUB_ACTIONS=true -e SWIFT_VERSION=6.0 -e workspace=/swift-nio -e TEST_DEBUG=1 -e TEST_LOG_LEVEL=info swift:6.0-jammy bash -c swift --version && swift test -Xswiftc -warnings-as-errors --explicit-target-dependency-import-check error
```
### Motivation:
Nightly builds for 6.2 exist, we should test against them.
### Modifications:
Update the matrix nightly-next to point to 6.2. This will affect
downstream adopters but shouldn't break them because they don't gatet
PRs on this passing.
### Result:
nightly tests will run against Swift 6.2
An example of this working
https://github.com/apple/swift-nio/actions/runs/15185876449/job/42706027686?pr=3250
### Motivation:
Swift 5.9 is no longer supported and CI has been updated to no longer
require it, we should disable it by default.
### Modifications:
* Default Swift 5.9 CI jobs to disabled
### Result:
Swift 5.9 CI jobs will not run unless opted-in
Add and enable Swift 6.1 workflows
### Motivation:
Swift 6.1 has been released, we should add it to our CI coverage.
### Modifications:
* Update `appe/swift-nio/scripts/generate_matrix.sh`
* Update reusable adopters of `swift_test_matrix.yml`
* Update end-user adopter workflows of `swift_test_matrix.yml`
* Copy over test flags from Swift 6.0 jobs
### Result:
NIO tests against Swift 6.1 in CI and downstream repositories can
opt-in.
(Successful CI run with the workflows modified to use the changes on
this branch
https://github.com/apple/swift-nio/actions/runs/14400598096?pr=3196)
Use nightly_next as swift version
see https://github.com/apple/swift-nio/pull/3122
Motivation:
To not have to rename threshold directories when the nightly branch
changes.
Modifications:
* Use nightly_next as swift version in the matrix generation script
which
is picked up by the benchmark script.
* Move nightly-next thresholds and add legacy symlink
Result:
Benchmark thresholds will attempt to find directories named
nightly_next, not nightly_6_1.
Update generate matrix stript to use nightly_next
### Motivation:
Updating the CI parameters for changing nightly job targets with each
new Swift version (6.0, 6.1, ...) is onerous. Whilst this gives us some
value in the non-nightly pipelines by forcing adopters to apply thought
to what is applied to each supported version, the nightlies arguably
deliver less value in this regard as they tend to be non-required.
### Modifications:
Change flags to refer to nightly_next rather than nightly_6_1, implement
a shim so that the old environment variables still work.
### Result:
We will be able to modify adopter workflows to use nightly_next
terminology.
Example of a job where workflows are using the new matrix
https://github.com/apple/swift-nio/actions/runs/13520016728
### Motivation:
Active development has moved to 6.1 so the Swift 6.0 nightlies no longer
deliver much value.
### Modifications:
* Deprecate 6.0 nightly CI configuration parameters
* Introduce new 6.1 nightly CI configuration parameters
* Update the matrix generation script to handle 6.1
### Result:
* No more nightly 6.0 CI, 6.1 nightlies are introduced.
* Configuration for 6.0 nightlies no longer has any effect.
* All repos are automatically opted-in to 6.1 nightly linux pipelines
**even if they opted out of 6.0**.
### Motivation:
The use of 'swift' here is very arbitrary and adds no value. The object
is only there at all because GitHub Actions seems to require it.
### Modifications:
Rename the top-level object from 'swift' to 'config' to maybe add value
to the intent of the object and hopefully be less cryptic.
### Result:
Everything should just keep working.
Introduce and adopt a new method for defining test matrices,
`swift_test_matrix.yml`.
⚠️ Any external adopters of the unit tests, Cxx interop and benchmarks
workflows are automatically opted in to use the new infrastructure.
### Motivation:
* The current matrix workflow has the limitation that it only supports
pre-defined sets of variables which are explored in the test matrix. At
the moment this is a pre-defined set of Swift versions on Linux and
Windows.
* Adding more means hard-coding them at multiple levels of the workflow
hierarchy.
* Currently skipped Windows matrix jobs show up as successes in the
GitHub UI leading to a misleading impression of good coverage.
### Modifications:
Introduce and adopt a new method for defining test matrices,
`swift_test_matrix.yml`. The new method is based around the approach of
defining the test matrix via a JSON object which may be supplied via an
input string from another workflow or from a file on-disk in a
repository.
Taking this approach means that we have the ability to add new targets
to the matrix simply by adding new elements to the JSON array,
increasing flexibility and the scope for future growth.
The unit tests, Cxx interop and benchmarks workflows are all modified to
use the new approach, this opts-in all downstream adopters. This should
be transparent to all downstream adopters.
In order to unify the Linux and Windows jobs I removed the use of the
`container:` GitHub Actions affordance in the Linux jobs which
transparently means all steps are executed within the nested container.
Instead we must manually call in to the docker container which
complicates scripting a little. I tested to see if doing this slowed
down the jobs (perhaps GitHub was caching the docker images more
intelligently) but it does not.
This approach follows the pattern of @FranzBusch 's open PR
https://github.com/apple/swift-nio/pull/2942
### Result:
* More flexible test matrix definitions
* No more false-passes for disabled Windows targets
Franz Busch
Rick Newton-Rogers
Fabian Fett