Closed JanWittler closed 2 years ago
As part of this restructuring I was wondering if we even need to run the nightly build every night? Source changes and new releases are published immediately anyway due to the triggers on push on master and creation of tags. I see that it makes sense to check regularly whether the build still works (due to dependency or environment changes) but wouldn't it be sufficient to do this once a week or once a month?
We once decided to run the build that often because sometimes updates of dependencies (fetched from the Eclipse updatesite) are API breaking. If the dependencies change between the last "nightly"/regular run and, for example, submitting a pull request, it can take some time to understand that an error is not coming from the changes in the pull request but from the broken dependencies. Thus, these nightly builds provide fast feedback for breaking API changes in the dependencies.
However, we could think about running the validation only for one OS every night and run those for the other OSes only on PRs or a less frequent basis. I would expect breaking changes in the dependencies to affect only a specific OS very seldom.
The Windows builds are currently failing because it seems the used Windows shell (PowerShell) is not able to parse the command correctly. For example, ./mvnw -B -U clean verify -Dstyle.color=always
results in Unknown lifecycle phase ".color=always"
. Unfortunately, I can't test on Windows, could someone please provide a corrected script?
Edit: Seems I already found the solution. PowerShell requires the stop parsing token
.
It seems that the dot separates arguments in PowerShell, i.e. ./mvnw clean verify -Dstyle.color=always
has the arguments clean
, verify
, -Dstyle
, and color=always
.
Putting those arguments into quotes should work: ./mvnw -B -U clean verify '-Dstyle.color=always'
As outdated and not anymore the root of all CI builds, this PR is closed and replaced by https://github.com/vitruv-tools/Vitruv-Change/pull/24
This PR adds support to run the validation GitHub Actions on all major OS (Linux, Windows, macOS). Releases are still built and released on Ubuntu.
Due to limitations in the GitHub actions expressivity, some workarounds were necessary: 1) The release process was extracted into a separate actions file (
release.yml
) to prevent running it on all runners while only Linux is needed. Conditionally constructing the Matrix based on the trigger would be preferred, however a ternary operator ((trigger == pr || trigger == push.master) ? <all_runners> : <linux>
) is not yet integrated into the syntax. There are proposed workarounds but I would consider them unstable and therefore not use them. 2) The duplicated execution of packaging the framework is preserved. A preferred solution would be to have individual jobs for each repository in the pipeline and declaring their dependencies. However, this becomes messy as runners can only be specified job-based instead of workflow-based and there is no lightweight mechanic for sharing the job output of one job with the subsequent jobs based on the runner.⚠️ Before merging this, the branch protection rules need to be adjusted to the modified job names ⚠️