-
-
Notifications
You must be signed in to change notification settings - Fork 382
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[TEST] Push CI jobs for draft PRs to PR author's personal forks of Mill #3540
Closed
Conversation
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
…oyi#3970) This sets up the scaffolding for com-lihaoyi#3928 and com-lihaoyi#3927 to be implemented
* [x] Needs com-lihaoyi#3919 as this builds on it * [x] Update this to use com-lihaoyi#3961, switching to `KtlintModule` * [x] Needs com-lihaoyi#3966 to disable ktlint for some files Last change I think needed for com-lihaoyi#3829 Overview: * Changes `KtfmtModule` to set the error code when there's changes like is true of the other formatters. * Some simplifications were made to the `example/package.mill` based on similarities with Java/Kotlin. * Files were formatted * CI was updated --------- Co-authored-by: Li Haoyi <[email protected]>
Fixes com-lihaoyi#3955. * We make `runBackground` forward the stdout/stderr to `$serverDir/{stdout,stderr}` instead of `os.Inherit`. This is necessary because since we started using com-lihaoyi/os-lib@59b5fd9, `os.Inherit` is automatically pumped to the enclosing task logger, which for `runBackground` ends up being closed immediately so the logs are lost. * Now, the logs are instead picked up asynchronously by the `FileToStreamTailer` infrastructure, which picks them up and forwards them to any connected client regardless of who started the runBackground process * Moved usage of `FileToStreamTailer` from the mill client to the server. * This allows better integration with the Mill logging infrastructure, e.g. ensuring tailed logs properly interact with the multi-line prompt by clearing the prompt before being printed and re-printing the prompt after. * Simplified `BackgroundWrapper` * Renamed it `MillBackgroundWrapper` so it's more clear what it is when seen in `jps` * Use a file-lock for mutex, rather than polling on the process uuid/tombstone files * We still need to add a `Thread.sleep` after we take the lock, because the prior process seems to still hold on to sockets for some period of time. This defaults to 500ms (what is necessary experimentally) but is configurable by the new `runBackgroundRestartDelayMillis: T[Int]` task * Generally unified the creation/shutdown logic within `MillBackgroundWrapper`, rather than having it split between `BackgroundWrapper` and `def backgroundSetup` in the Mill server process Tested manually by running `rm -rf out && /Users/lihaoyi/Github/mill/target/mill-release -w runBackground` inside `example/javalib/web/1-hello-jetty`. Forced updates via `Enter` in the terminal or via editing server source files. Verified that the `runBackground` server logs appear in the console and that they do not conflict with the multi-line status prompt
Added [Revapi](https://revapi.org/revapi-site/main/index.html) support for API analysis and change tracking to identify incompatibilities. Resolves com-lihaoyi#3929.
Covers the improvement we implemented in com-lihaoyi#3971. Fails on any commit before that PR
…#3965) # Pull Request Added Kotlin Example for Spring Boot Fixes: com-lihaoyi#3963 ## Description Adds Example for Kotlin Spring Boot `6-hello-spring-boot` and `7-todo-spring-boot` ## Related Issues - Link to related issue com-lihaoyi#3963. ## Checklist - [x] New Example For Kotlin Spring Boot Hello World - [x] New Example for Kotlin Spring Boot Todo MVC ## Status Completed Addition
This is a precaution for cases when the `.mill-version` file can contain a Windows line end `\r\n` instead of the typical Unix line end `\n`. Without this fix, in such situation the script breaks in a spectacular and surprising way. The error it was giving looked like this: ```sh $ mill __.compile curl: (3) URL using bad/illegal format or missing URL ``` Where `mill` is pointing to the wrapper script that I'm changing in this PR
This changes discovery of test classes for Junit5, to be in line with that of sbt-jupiter-interface. Closes com-lihaoyi#3910
Follow up from com-lihaoyi#3900 Co-authored-by: Georg Ofenbeck - taaofge1 <[email protected]>
This info may be still valuable to debug IDE issues as well as running with more rare setups like `vim` or `emacs`. Inspired by com-lihaoyi#3976 from [@sideeffffect](https://github.com/sideeffffect) Pull request: com-lihaoyi#3989
This adds a `JavaModule#resolutionParams` task, allowing users to customize coursier's [`ResolutionParams`](https://github.com/coursier/coursier/blob/b04937dda13cee80b3743c84f471a69eb430047e/modules/coursier/shared/src/main/scala/coursier/params/ResolutionParams.scala). These allow to customize some aspects of dependency resolution. In particular, `ResolutionParams#enableDependencyOverrides`, when set to `Some(false)`, disables the recent BOM changes added (and enabled by default) in coursier `2.1.17`. This might be useful, if ever users aren't happy with the versions it selects, or want to wait a bit before enabling that, or if they find out performance suffers because of it for them. The new task is anonymous (it's not a target, it's not serialized on disk), as `ResolutionParams` has a field that doesn't easily lend itself to serialization (`rules`, because of the `Rule` type, which is an open abstract class).
…i#3987) In the current version the SonatypeCentralPublishModule has non intented behaviour with PublishModule.defaultGpgArgs. It will default to the args without a passphrase and afterwards ignore the passphrase env. var as a gpgarg is already set. To get the "correct" behaviour one has to override the args with an empty string to then pick up the "PGP_PASSPHRASE" env. arg. Also changed the env. name to match the one from SonaTypePublisher "PGP_PASSPHRASE" -> "MILL_PGP_PASSPHRASE". Currently pgp and gpg are getting used both in terms of naming - guessing going for gpg in the future might be more clear. Co-authored-by: Georg Ofenbeck - taaofge1 <[email protected]>
Fixes com-lihaoyi#3480. Changes: - adds `coursier-jvm` as a dependency to the `util` module, this library is for fetching JVMs using coursier and the coursier [jvm-index](https://github.com/coursier/jvm-index) - add a `def javaHome: Task[Option[PathRef]]` task to `ZincWorkerModule`. This defaults to `None`, which is the existing behavior of using mill's java home. - Users who want to use a custom JVM need to define a custom `ZincWorkerModule` and override `def jvmId`, optionally `def jvmIndexVersion` - updates the `mockito` and `commons-io` examples to use the new configuration options. Now these examples should run even when mill itself is not running on java 11. - This also required adding `-encoding utf-8` to the projects' javac options. - update the `run` and `test` tasks to use the `zincWorker`'s java home if a different one specified Notes: * `JavaModule#compile` forks a new JVM for each compilation to support custom JVM versions, and `ScalaModule#compile` does not support custom JVM versions at all. This would require a deeper refactoring of `ZincWorkerModule` to fix * --------- Co-authored-by: Li Haoyi <[email protected]>
Now that we'll have an OS-X publishing job for native image, we need to make sure that some basic smoketests pass on PRs before we merge them
Needed some fixes in the bootstrap scripts to prevent the enclosing environment from leaking through. We can then remove the `setup-java` step from all of our workflows, since the Mill native executable will bootstrap the JVM as necessary We can now run most of github actions jobs without installing Java beforehand, except for the `pre-build` step where `selective.prepare` step which runs on `main` and thus does not have these changes. Once this PR is merged, we can remove `setup-java` from `pre-build` as well
- Need to move from `temurin:17` to `zulu:17` to get things working on my windows-arm laptop (temurin did not back-publish older JVMs for windows-arm) - Get rid of the custom `pathingJar` we defined in `dist/package.mill` (using custom path rendering) which doesn't seem to work, in exchange for the default `Jvm.createClasspathPassingJar` (using path-as-url rendering) that does seem to work - Make `def launcher` make use of `runUseArgsFile` similarly to the various `run` tasks - Make the integration tests use the `./mill.bat` launcher on windows, rather than `./mill` as a shell script, as the shell script doesn't seem to work properly when used in a windows environment
* Drop windows `contrib.__.test` job; it's very slow (for some reason much slower than the linux version) and basically has never caught anything * Move entire `example.scalalib.__.local.server.test` job onto mac, to exercise a wider set of functionality there, and remove the Linux version of the job
…example tests. (com-lihaoyi#4304) Previously we copy-pasted it twice between Integration/Example-Tester and still missed a spot, this puts it in a global that we can use in all three places
lihaoyi
added a commit
that referenced
this pull request
Jan 14, 2025
…3543) This PR aims to reduce the bottleneck of contributors waiting for CI jobs on the shared Mill repo by moving CI for draft/WIP pull requests to each contributor's own fork, each of which has a separate concurrency budget (~20 concurrent workers) from the `com-lihaoyi` organization. Once a PR is marked ready-for-review, `com-lihaoyi` CI begins, so the author effectively has a choice of where they want to run their CI workloads. Mill's main PR validation CI jobs are portable, do not need any special secrets or environment, and can run just fine in contributor's GH Actions environments To do this: * Made the upstream `build-linux`/`build-windows`/`test-docs` CI jobs filter on `github.event.pull_request.draft == false`, and * Removed the `branches: - main` filter on the `run-tests` jobs so they begin running in contributor GH Actions when commits are pushed to a branch * Add a new `Draft CI` workflow that pushes a github status linking to the PR's branch in the contributor's fork, as an easy way to see the CI history for the PR there. This needs to run on `pull_request_target` rather than just `pull_request` to have the suitable permissions to update statuses * Some subtleties around handling `ready_for_review` events such that when a contributor marks a PR as ready for review, CI is re-triggered and handled appropriately without needing to subsequently push a new commit. * Substituted `github.head_ref` with `github.ref_name` in the `concurrency.group` key since the former only works on PR events while the latter also works on push events This is a bit of an unusual setup AFAIK for Github Actions, but I've tested it manually a bunch and it seems to work, and should mitigate the bottleneck of multiple people updating their WIP PRs and having everyone blocked waiting on everyone else. Worst come to worst, if you mark a PR as `ready_for_review` it falls back to the old behavior, but this setup gives you an option to run draft PR validation on your own fork's GH Actions where it won't get blocked by other people's PRs. This is something you can actually already do today, but it requires some tedious fiddling that PR makes seamless Tested on #3540 via `git commit -am . --allow-empty && git commit -am . --allow-empty && git push origin head && git push upstream head~1:test-non-draft && git commit -am . --allow-empty && git push origin head`, and targeting this PR against the `test-non-draft` branch in the Mill repo
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Tested via
git commit -am . --allow-empty && git commit -am . --allow-empty && git push origin head && git push upstream head~1:test-non-draft && git commit -am . --allow-empty && git push origin head