Generation Software Bill of Materials (SBOM) #4314
Draft
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
gamlerhart
changed the title
gamlerhart
commented
Jan 13, 2025
gamlerhart
commented
Jan 13, 2025
| import java.time.Instant | ||
| import java.util.{Base64, UUID} | ||
|
|
||
| object CycloneDXModule { |
There was a problem hiding this comment.
Ignore the Module: Needs a bit more work =).
gamlerhart
force-pushed
the
experiment-sbom
branch
from
bf2912d to
7978b13
Compare
gamlerhart
changed the title
gamlerhart
force-pushed
the
experiment-sbom
branch
3 times, most recently
from
072d39a to
e9307ac
Compare
gamlerhart
force-pushed
the
experiment-sbom
branch
from
e9307ac to
04b6187
Compare
…om-lihaoyi#4270) This was referenced in com-lihaoyi#4269. This checks for m2 (Maven)
Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com>
Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com>
…#4356) ## Provided in this PR After running Instrumental tests the XML will automatically created in the **out/app/it/testTask.dest/** directory  ## JUnit XML validation Using this online tool [link](https://lotterfriends.github.io/online-junit-parser/#case.0.0) we can validate that the XML is correct 
Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com>
…ommand (com-lihaoyi#3257) Fixes com-lihaoyi#3132 Pull Request: com-lihaoyi#3257 --------- Co-authored-by: Li Haoyi <[email protected]>
The PR adds non-regression tests for BOM use in `compileIvyDeps` and `runIvyDeps`, and makes sure BOMs of a module can be used in its test modules. --------- Co-authored-by: Li Haoyi <[email protected]>
The mac-latest and mac-13 workers seem significantly slower than the default linux worker, so just run a single thirdparty example as a smoketest on each one
…ral (com-lihaoyi#4386) Fixes com-lihaoyi#4373 This only affects people running clicking links or running commands manually to download the bootstrap scripts or example projects, or manually running `./mill init`, so it won't break any automated releases. This lets us substantially simplify the github actions workflows and build config
The Mill Client only forwards requests and therefore does not need much memory. However, Java doesn't know that an allocates a large heap based on the machines memory size. Therefore, give a way lower heap limit, creating a leaner client memory wise. Example on my machine: - Before: A Mill client reserved ~500MByte - After: A Mill client reserves the specified 24Mbyte This is mostly relevant for a long running mill client (examples `--watch` clients, `-i --no-build-lock` and --bsp`). Co-authored-by: Li Haoyi <[email protected]>
…m-lihaoyi#4362) ## This PR provides - ability to import a mill android project to android studio via BSP, including sources and generated sources. - necessary changes to the way sources are resolved (through module dependency instead of class inheritance). - Changes to tests (e.g. number of sources compiled) reflect these changes ### Not provided - Compilation still needs to be done from the command line in order for the paths to be resolved inside the IDE. Note that to make compilation, running, testing and debugging work from android studio, we'll need to develop a plugin for it ## Note This is an early draft and I need to cleanup or review a few rough edges, I submit this as a draft to get some early feedback. I've implemented java to get the basics to work, as kotlin has multiple kinds of sources and files that need to be taken care of, so this is just a small step. Don't hesitate to point out any issues as I've really just braced through and hacked around to get this to work! @0xnm @lihaoyi any feedback will be appreciated! ## Android Studio Integration The attempt focuses on BSP. Although bsp as a plugin does not seem to be available for android studio, it strangely becomes available if it is installed through intelliJ (see video) ### Basic changes - Use the moduleDeps instead of resolving the classpath bits (sources, resources) through inheritance. This makes BSP and studio integration work (see the directories that are highlighted correctly) - Crude implementation of bsp methods to get the IDE to report the imported modules correctly ### Tricky parts - Resources are compiled twice due to how aapt linking and later the module deps compile hierarchy. In order to avoid this, I've added an empty generatedSources method in android instrumentation module . ### Demo You can see in the demo most of the IDE static import features work (R is not recognised but I'll look into it either in this PR or subsequent). https://github.com/user-attachments/assets/77fe5e52-57e7-4480-9971-b50cc8d4d839 EDIT: I've fixed the R not being recognised and the kotlin import  EDIT 2: Added summary at the top
Like the title says, this option allows users of the `scalapb`-Plugin to submit the option `scala3_sources` to `scalapb` directly. --------- Co-authored-by: Björn Eyselein <[email protected]> Co-authored-by: Li Haoyi <[email protected]> Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com>
The actual analysis is delegated to the well-known coverage.py package.
* Increase `-j` parallelism to 0.75C to try and saturate the CPU * Move android parallelism limit out of `action.yml`, where the `if` condition was for some reason not evaluating properly * Split up some big integration suites to take advantage of `testForkGrouping` Fixes com-lihaoyi#4440. Manually looked at the CI logs to see that the test command is now running without `-j1` and the status ticker is showing multiple tasks running at once --------- Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com>
…al (com-lihaoyi#4340) This needs to wait until Graal support in Mill is released in 0.12.6
The earlier PR defined `ExampleCrossModuleAndroid` but didn't use it --------- Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com>
This is work in progress to fix com-lihaoyi#3152 Numerous fixes were also needed to com-lihaoyi/mainargs, com-lihaoyi/sourcecode, and com-lihaoyi/mill-moduledefs With the current state, only 1 example/integration tests is still failing: - `integration.feature[plugin-classpath].local` known TODOs: - [x] Discover macro - [x] Applicative macro - [x] Caller macro - [x] Cross.Factory macro - [x] EnclosingClass macro - [x] Task macros - [x] Cacher macro - [x] Moduledefs compiler plugin (override inferrence) - [x] All core Mill modules compile with Scala 3.5.0 - [x] Fix Zinc reporter patch linenumbers of build scripts - [x] Check that bytecode analyzers work with Scala 3 - [x] cleanup library dependency conflicts - [x] Support new Scala 3 syntax in build.sc files - [x] ~Fix BSP reporter linenumbers for build scripts~ (Zinc reporter forwards to bsp) - [ ] Cleanup compiler warnings for outdated syntax known incompatibilities: - [ ] can't use `ExplicitResultTypes` scalafix rule - need to upgrade mill-scalafix - [x] ~`Cross.scala` uses the new quoted type syntax which scalafmt crashes on, (and version is frozen) so skip the file~ upgraded Scalafmt so not skipped anymore - [ ] skipping Mima currently due to 1000s of errors (perhaps we should generate filters?) - [ ] filtered one flaky test from `example.thirdparty[mockito]` - [ ] filtered out `integration.feature[plugin-classpath]` due to third party plugin dep --------- Co-authored-by: Li Haoyi <[email protected]>
Changelog https://com-lihaoyi.github.io/upickle/#4.0.0 This is a binary incompatible change and will need to go into 0.13.0
…i#4452) (com-lihaoyi#4454) Resolve com-lihaoyi#4451 It seems that `transitiveCoursierProjects` is populated with repetitive transitive modules, that's why it only causes problem for large build. Please open all PRs as drafts and ensure that your fork of Mill has `settings/actions` / `Allow all actions and reusable workflows` enabled to run CI on your own fork of the Mill repo. Only once CI passes mark the PR as `Ready for review` and CI will run on the main Mill repo before we merge it. Co-authored-by: Mai Huy Hoàng <[email protected]>
* Make `Discover` return a `class` (that can be evolved by adding fields) rather than a `Tuple` (which cannot) * Simplify handling of `millDiscover` flags, in particular we do not need them to be defined for subfolder base modules * Remove unused `ObjectDataInstrument`, `Snippet`, `ObjectData` * Remove `MILL_SPLICED_CODE_START_MARKER` --------- Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com>
gamlerhart
force-pushed
the
experiment-sbom
branch
from
647cbbd to
16518bf
Compare
Motivation: Often larger projects need a Software Bill of Materials (SBOM) to track dependencies across their projects. So the project can track things like vulnerable components, licenses etc. - Refactor Coursier support to return the original dependency as well. - Start of support for CycloneDX format
gamlerhart
force-pushed
the
experiment-sbom
branch
from
16518bf to
55cdb7e
Compare
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.
Motivation: Often larger projects need a
Software Bill of Materials (SBOM) to track dependencies across their projects.
So the project can track things like vulnerable
components, licenses etc.
This is more a QnA pull request.