Bumped version and prepared no artifact. This will be user from maste… #107
Workflow file for this run
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| # | |
| # GitHub runner workflow for building, verifying and testing the XVM repo. | |
| # | |
| # It also does some quick sanity check that we can provide release artifacts. This latter part | |
| # will be implemented in much better detail when we have a marge to master and minimal effort | |
| # GitHub release plugin integration, so we can automate release generation. | |
| # | |
| # TODO: Add a release workflow, and a distribution creation workflow. Reuse parts of the | |
| # "xdk-release" repo, that can run the cross product of aarch64, amd64, Linux, Windows and | |
| # MacOS, including creating the Windows "exe" installer, on any platform with Nsis. | |
| # | |
| # TODO: Add workflow jobs in another GitHub workflow configuration that builds SNAPSHOT releases | |
| # when a PR is merged into master. | |
| # | |
| # TODO: Discuss what other kinds of GitHub workflow actions we need. This can be anything | |
| # from cron jobs that run every night, to containerization tests/efforts/creations. | |
| # | |
| # TODO: Retain more build information than the defaults (log output and build scan links). I.e. | |
| # configure any build output files that we may want to inspect to be retained as well. | |
| # @see https://github.com/gradle/actions/blob/main/setup-gradle/README.md#github-dependency-graph-support | |
| # | |
| # TODO: Set up Discord channel chat messages, when an action is started, successful or fails. | |
| # | |
| # TODO: Verify that the build jobs run both with and without the build cache. Since it takes | |
| # time to rebuild the cache, the clean cache run should be a separate workflow, and it may be | |
| # a good idea to run it only on pull requests, not on every push, or something like that. | |
| # Another option is to have a GitHub cron job action, that nukes the caches every night, so that | |
| # at least the first GitHub workflow of the day is known to build with a clean cache. | |
| # | |
| # TODO: File these TODOs as issues in the GitHub repository. | |
| # | |
| name: XVM Repository build, test and verification runner. | |
| on: push | |
| # on: pull_request | |
| env: | |
| # | |
| # This turns into a project property that outputs some important lines of the XTC plugin logic to the console. | |
| # The flag is intended to provide enough information to do a reproducible run for any action performed by the Plugin. | |
| # | |
| ORG_XTCLANG_PLUGIN_VERBOSE: true | |
| # | |
| # The following flags were intended to be used to finish the build run with a simple sanity check, compiling | |
| # and running a text program, making sure that both the build DSL and the mechanism for consuming the | |
| # XDK being worked on as an artifact have not been broken. | |
| # | |
| # TODO: These will go away. We will add a separate job to do this to this workflow. | |
| # | |
| ORG_XTCLANG_BUILD_SANITY_CHECK_RUNTIME: true | |
| ORG_XTCLANG_BUILD_SANITY_CHECK_RUNTIME_FORCE_REBUILD: false | |
| # Provide debug information of all build cache actions: | |
| GRADLE_BUILD_ACTION_CACHE_DEBUG_ENABLED: true | |
| jobs: | |
| gradle: | |
| # If we do not specify a version here, the runner will pick up whatever Gradle version | |
| # that is defined by our wrapper, which is exactly what we want. | |
| strategy: | |
| matrix: | |
| os: [ ubuntu-latest, windows-latest ] | |
| # The verification actions are run on Linux and on Windows. There are MacOS runners available from GitHub, | |
| # but they are rarer, which may lead to increased test times. Of course we should always make sure that | |
| # the project builds and runs on all our target platforms, but for time being, we just verify Linux and Windows | |
| # builds. Also note that the MacOS runners available for free are all x86 machines, whereas cycles on aarch64 | |
| # MacOS machines are charged for by GitHub. | |
| runs-on: ${{ matrix.os }} | |
| steps: | |
| # 1. Checkout the repository under test. | |
| - uses: actions/checkout@v4 | |
| # 2. Set up the Java JDK. The JDK vendor should not matter, but we require Java 21. | |
| - uses: actions/setup-java@v4 | |
| with: | |
| distribution: 'temurin' | |
| java-version: '21' | |
| # | |
| # 3. Configure a Gradle build action. | |
| # | |
| # The current version of this GitHub action is v2.4.2, is at the time of writing still considered | |
| # secure, and has fixed previous issues with leaking secrets to the build cache in the GitHub runner | |
| # container. Dependabot will alert us to any newly discovered security problems. | |
| # | |
| # @see: https://github.com/gradle/gradle-build-action#readme | |
| # @see: https://github.com/gradle/gradle-build-action?tab=readme-ov-file#select-which-branches-should-write-to-the-cache | |
| # | |
| # By default, the Gradle action will only write to the cache from jobs on the 'master' branch. | |
| # it is also possible exclude certain parts of the build from the cache, with: | |
| # | |
| # @see: https://github.com/gradle/actions/blob/main/setup-gradle/README.md#exclude-content-from-gradle-user-home-cache | |
| # | |
| - name: Setup Gradle | |
| uses: gradle/gradle-build-action@v2.4.2 | |
| # 4. Run the Gradle build, with verbose logs, and stack traces enabled to verify it works. | |
| - name: Verify Gradle Build | |
| run: ./gradlew build --info --stacktrace | |
| # 5. Run the Gradle installation tasks to verify that we can create distributions, and that their | |
| # layouts are correct. | |
| - name: Verify Gradle Install and Distribution Layout | |
| run: ./gradlew installDist --info --stacktrace | |
| # 6. Run the Gradle installLocalDist task, and verify that its output works as expected. | |
| # TODO | |
| # TODO: We need to figure out how to communicate success or failure as long as the manual tests are | |
| # not integrated into test source sets / unit tests for XTC / XUnit, or whatever test harnesses | |
| # we may want to use. | |
| # | |
| # TODO: A good shortcut to have, would be if tasks or extensions could grab configuration from properties | |
| # too, even though this should really not matter for a properly setup IDE. For exmaple, force rebuild | |
| # of a particular task in a particular project could maybe be -PmanualTests_tasks_runXtc_forceRebuild=true | |
| #- name: includeBuild manualTests; make sure its default is to run as if -PtestName=TestSimple were set. | |
| # run: ./gradlew manualTests:runXtc -PmanualTests=true --info --stacktrace | |
| #- name: includeBuild manualTests; make sure we can a single test, pointed out by the property testName | |
| # run: ./gradlew manualTests:runXtc -PmanualTests=true -PtestName=TestFizzBuzz -PtestArgs="Hello","World" --info --stacktrace | |
| #- name: includeBuild manualTests; run all tests through the parallel XTC Runner | |
| # run: ./gradlew manualTests:runXtc -PmanualTests=true -PtestName=all --info --stacktrace |