virtuslab/community-build3

community-build3's Issues

Handle manual rebuilds correctly

If one tries to rebuild a failed job (e.g. because formerly the executor ran out of resources), after the build finishes (with a success or failure) downstream jobs are triggered for rebuilding. Currently, even if they succeeded before they will fail on publishing artifacts during the rebuild because the artifacts repository doesn't allow reuploads. What should be done in such cases? E.g.

1. Don't rebuild downstream jobs if they were built successfully before - but then we won't know whether using the newly build artifacts from the upstream job would change anything
2. Allow reauploading artifacts - should we then invalidate the results of all transitively downstream jobs and stop the ones that are currently running?

Don't fail reporting to Elasticsearch for long build summary or logs

Use --rawfile option of jq for values taken from files

Include generating documentation as a build step

Design a way to aggreagate and preserve data that allows post-morten analysis

Do not override depedencies if given scope failed to publish.

Detect java to use

So far running cb on java 8 failed some projects. We should try to detect required java version based on e.g. gh action

[Placeholder] Support for 3rd parties

Allow companies to build against given build and provide back the stats.

Add configuration setting for disabling running tests in projects (only compile and publish)

Proper approch to signing the local artifacts

For now I am forced to disable signing at all

Prepare way to reproduce run of single project

This should also allow to test 3rd party code against given instance of community build.

Create mechanism for project specifi configuration

JVM settings for sbt (-Xmx)
ignore targets (e.b. catsefffext/xx/test)
add more test targest (e.g. integration-tests/test)
override timeout

This should be defined within the repo but for not we should keep it on our side

Scrapping Scaladex should support dynamically generated data

Content of Scaladex versions matrix is not a static page - the content is being dynamically generated upon scrolling the page. For most of the projects that are not an issue, however, Scaladex can also contain snapshot version entries (scalacenter/scaladex#927) for which we should not run the build as they're not stable, and we accept only official (pre-)releases.
If the project contains a lot of snapshots we might not be able to get the last official release in the initial results scrapped using JSoup, (we have that problem with http4s) and though would be not able to resolve names of the artefacts produced by the given version. It would also lead to building a project using main branch, instead of using stable state assigned to given version tag.

Allow to specify additional scalacOptions for all builded projects

Add support for Mill

Post-build summary

Investigate Scala 2 community build

How scala 2 handle:

• a project with 2 different versions
• native vs js
• running all tests projects?
• is there any mechanism to make sure that all deps are translated
• what found most problems?

Maven repo needs a cron job to remove stale builds

Currently, the Maven repo requests a disc space for the size of 5Gb, it lasts for ~4 weeks of running nightly builds. after that time we would run out of disc space and builds would start to fail.
We should set up a Kubernetes job that would remove stale builds, eg. older than 1 week.

Measure coverage of compiled dependecies

For each target

Handle different java versions

Some projects might have some specific requirements regarding the version of java used to compile them.
E.g. typelevel/fs2 uses java.net.StandardProtocolFamily.UNIX which seems to be available only from JDK 16 on.

Could we somehow make such projects build successfully?

Allow to specify additional project targets in config

We currently build only projects/sub-modules with published artifacts on Scaladex (via producing a target mapping). Some projects might define a separate sub-module for tests. Becouse these modules would never be published, we would never include them in targets. Good example can be softwaremill/magnolia
We should allow to specify additional targets for given project in config

Add a SOP of how to submit projects

HI, thanks for this, but there are many texts in the documents, is there any SOP for how to submit a project to the community build?

Jenkins public read only permissions

In the future we should set up permissions for not authorized users, to allow read-only access to Jenkins access.

Mechanism to compute graph-based stats

We want to e.g. know how many 'indirect' starts / depended source lines etc. given source has used different distribution stragties (e.g. pass X% and/or dive passed value based on amount of dependencies that project has)

Find mechanism to aggregate measure and results

Each run of community build will provide a lot of data. We want to find a mechanism to aggregate and store that data.

There is not hard stop how many features we would like to have so I split them into 'must have' and 'nice to have'.

Must have

• allow to gather and aggregate data on few levels (run of community build, build of a single project and finally run of single target)
• gather numerical data like no. of warning, errors, failed tests or line compiled. It should also include compilation speed, times, or sizes generated .classes and .jar files
• allow to report data from distributed build
• allow to aggregate across different runs (e.g. we want to display time of compilation for given project across many builds)
• generating reports should be easy
• easy way to anonymize data

** nice to have **

• ability to track failures of single test
• ability to track compilation problems / warning

We would prefer to use some lightweight solution.

Prepare metrics and compare different ways to generate depenedencies graph

Test: mvn central vs. libraryDependencies vs. actual classpath

Metrics: compiled scopes, failed scopes / tests coverage of dependencies, compiled source files

Build should timeout

Create sbt plugin introducing community build aware API

We might publish an sbt plugin allowing easier conditions checks that would be aware of community build. It can help us for easier manipulation of the builds to fully support nightly versions of Scala compiler

Create proposal of new community build design

TODO:

• define mechanisms to define custom behaviour (targets and test tasks, plus custom scalac options)
• build graph using .ivy files
• build graph using sbt projects (with caching)
• measure coverage of updated deps on classpath
• compare both mechanisms and pick best for Open Community Build
• apply .sbt graph mechanism into Managed Community Build
• prepare reporting mechanism after each run of Open Community Build
• dist generated artefacts and prepare steps for easy reproduction of builds of single projects (include that in reports)
• add the possibility for a downstream community build to kick in
• allow companies to provide us with stats about their builds (with different degree of anonymization)

Allow per-target overrides

e.g. munit-cats-effect depends on 2 different version of cats effect