Fake build project and GitHub actions per scenario#739
Conversation
There was a problem hiding this comment.
Pull Request Overview
This PR introduces a new FAKE-based build project, replaces the old build.fsx script, adds AltCover support in tests, and configures multiple GitHub Actions workflows.
- Add AltCover package to test projects for code coverage
- Create
build/build.fsprojandbuild/build.fsas the new FAKE build setup, with accompanying wrappers (build.sh/build.cmd) - Remove legacy
build.fsx, update solution files, central package versions, and add CI/CD GitHub workflows
Reviewed Changes
Copilot reviewed 24 out of 25 changed files in this pull request and generated 2 comments.
Show a summary per file
| File | Description |
|---|---|
| tests//.fsproj | Added <PackageReference Include="altcover" /> to enable coverage instrumentation |
| build/build.fsproj | New FAKE build project with dependencies |
| build/build.fs | New F# script implementing build targets |
| build.sh / build.cmd | Shell and Windows wrappers for invoking FAKE build |
| build.fsx | Removed legacy build script |
| Directory.Packages.props | Reorganized package version groups |
| .github/workflows/*.yml | Added multiple workflows for build, publish, and docs deployment |
Comments suppressed due to low confidence (1)
build/build.fs:92
- The
changelogBackupFilenamemutable value is declared but never used within this script. Consider removing it to reduce dead code.
let mutable changelogBackupFilename = ""
| |> Seq.map (fun t -> t.Name) | ||
| |> Seq.exists ((=) "PublishToNuGet") | ||
|
|
||
| let invokeAsync f = async { f () } |
There was a problem hiding this comment.
Prefer using the task computation expression over async here (e.g., let invokeAsync f = task { f () }) to align with the project’s guidelines.
There was a problem hiding this comment.
Disagree, Copilot. async is idiomatic F#, task is not (it was created for better interoperability with C#)
There was a problem hiding this comment.
It is according to the Copilot instructions file.
https://github.com/fsprojects/FSharpLint/pull/726/files
If you want to suggest any changes in that PR I will review
|
@knocte @Numpsy @webwarrior-ws I've updated CI to cover more scenarios. Give your feedback, please. |
| @@ -0,0 +1,73 @@ | |||
| name: Build `master` | |||
There was a problem hiding this comment.
@xperiandri no need to rename the workflow file because this still builds & run tests. Also no need to rename workflow name because PRs should run CI too (and PRs are not 'master')
There was a problem hiding this comment.
But the name was build+test+deploy.yml and now it does not deploy anything. Only builds and tests. Do you still want to have the same name?
There was a problem hiding this comment.
having it same name would, to begin with, allow to have a proper diff to comment on; and I'm not convinced about moving the deploy parts of the CI to another file because you're basically moving logic from F# to GithubActions syntax, so basically undoing some work we have done in the past
There was a problem hiding this comment.
The main purpose of having multiple pipelines is the separation of responsibility. You always know which file responsible for what.
Also, I reconsolidated Fornax build logic into the Fake build project. So that the docs build is encapsulated into a build target.
@webwarrior-ws, what do you think?
fa526b5 to
c33ab51
Compare
| - name: Setup .NET | ||
| uses: actions/setup-dotnet@v4 | ||
| with: | ||
| dotnet-version: ${{ env.DOTNET_VERSION }} | ||
|
|
||
| - name: Restore tools | ||
| run: dotnet tool restore | ||
| - name: Restore dependencies | ||
| run: dotnet restore | ||
| - name: Run Fornax | ||
| run: dotnet fsi build.fsx -t Docs | ||
| - name: Deploy (if tag) | ||
| if: startsWith(github.ref, 'refs/tags/') | ||
| uses: peaceiris/actions-gh-pages@v3 |
There was a problem hiding this comment.
Now all of this is done in Fake via a designated target
| - master | ||
| pull_request: | ||
| branches: | ||
| - master |
There was a problem hiding this comment.
@xperiandri doing the above will make PRs not have CI feedback; please revert all these changes in the workflow above
| - windows-latest | ||
| - macOS-latest | ||
| configuration: [Debug, Release] | ||
| os: [ubuntu-latest, windows-latest, macOS-latest] |
There was a problem hiding this comment.
@xperiandri there's no need to change the os attribute for no reason, you're just causing git-blame line-damage here
| - name: Build via Bash | ||
| if: runner.os != 'Windows' | ||
| run: | | ||
| chmod +x ./build.sh |
There was a problem hiding this comment.
@xperiandri let's just add the +x attrib to the file in github to not need to use chmod here
| publish_branch: gh-pages | ||
| force_orphan: true | ||
| runCmd: | | ||
| chmod +x ./build.sh |
| on: | ||
| # Runs on pushes targeting the default branch | ||
| push: | ||
| branches: ["master"] |
There was a problem hiding this comment.
@xperiandri we want PRs to the docs to also be tested before being merged, so please stop using the branches attribute, it is a bad practice
|
|
||
| - name: Build Docs | ||
| run: | | ||
| chmod +x ./build.sh |
| on: | ||
| push: | ||
| branches: | ||
| - master |
There was a problem hiding this comment.
@xperiandri even if we only want to publish for master branch, the way to filter it is to prevent the last step from happening (the nuget push) if branch is not master. This way the job is still being tested everytime, even for PRs.
| - name: Add the GitHub source | ||
| run: dotnet nuget add source --name "github.com" "https://nuget.pkg.github.com/fsprojects/index.json" | ||
|
|
||
| - name: Ensure NuGet package source mapping |
There was a problem hiding this comment.
@xperiandri what is this exactly? I would prefer a script instead of so much githubActions logic
There was a problem hiding this comment.
moved to build.fs
| on: | ||
| push: | ||
| tags: | ||
| - 'v*' |
There was a problem hiding this comment.
@xperiandri same point I mentioned about filtering to master branch applies here
| @@ -0,0 +1 @@ | |||
| dotnet run --project ./build/build.fsproj -- -t %* | |||
There was a problem hiding this comment.
@xperiandri I guess -t means --target? let's prefer to use longer flag names, shorter ones can be used when using the terminal to type faster, but for scripts we should favour readability
| set -eu | ||
| set -o pipefail | ||
|
|
||
| FAKE_DETAILED_ERRORS=true dotnet run --project ./build/build.fsproj -- -t "$@" |
cd55eca to
15505f9
Compare
|
@knocte, let's define the build strategy.
You suggest:
I propose:
|
|
Looks like a bug. It treats named parameter assignment as a condition |
It is. |
| tags: | ||
| - 'v*' | ||
| branches: | ||
| - master |
There was a problem hiding this comment.
@xperiandri I know that you have put '**' for pull_request, but still putting this filter here will mean that a contributor that is about to post a PR won't get CI feedback until she proposes the PR, which is unnecessary. Contributors should be able to see the CI statuses before creating PRs.
|
|
||
| # to execute once a day (more info see https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#schedule ) | ||
| schedule: | ||
| - cron: '0 0 * * *' |
There was a problem hiding this comment.
@xperiandri why remove the schedule? this way we make sure that CI is still working, and when it breaks for reasons unrelated to FSharpLint commits we notice right away. Before I added this schedule job it used to happen that suddenly some new commit landed in master and broke CI and we were scratching our heads for days wondering how that commit could break the build, until we realised the CI broke by itself, unrelated to the commit.
Not sure I understand what you're getting at in that big comment, Take in account there's already a build strategy in master branch so what you're trying to do in a PR is to change it. If you phrase the changes this way, I'll understand much better what you mean. For example, wrt the docs, you mean we shouldn't run fornax in master but only in tags? If that's the case, say it explicitly: stop doing X, start doing Y, etc. |
|
53634ab to
b173d9f
Compare
|
Migrated to #742 |
launchSettings.jsonwith multiple profiles to run the build projectmasteras prerelease GitHub packagesmasterand release tag creation