publish reproducibility data by artifacts

[hboutemy]

currently, reproducible central is organised to rebuild projects releases to check reproducibility: main concept is the project release build, with its specification as .buildspec (how to rebuild the release), the rebuild result as .buildinfo (what are the artifacts obtained), and the comparison of rebuild artifacts against Central reference as .buildinfo.compare

In the end, we want to be able to check if our dependencies are reproducible (in addition to our own build): we'll need to have reproducibility information keyed on artifacts

Then we need some way to store reproducibility data on artifacts in a by-artifact query-able way

[slawekjaranowski]

I see that .buildspec is redundant all information we have in .buildinfo.

When maven-artifact-plugin will be release - https://issues.apache.org/jira/browse/MARTIFACT-2 each project can easy publish this like standard artifact.

One is missing mvn.rebuild-args in .buildinfo

[hboutemy]

this is a feature of artifact:buildinfo goal that I currently postponed, because:

1. I doubt this will be easy for projects to configure this rebuild parameter
2. I needed to start rebuilding before projects start publishing .buildinfo file
3. even once .buildinfo files will be published to Central Repository with a good configuration, multi-module builds will still require to define which module contains the generated buildinfo file, which will be tricky to configure in the plugin configuration

welcome to the world of reproducible builds in Reproducible Central, where on each nice idea, you discover that it's not so easy :)

[slawekjaranowski]

1. if you think about rebuild-args simply this information should be required by plugin
2. we need two separate goals, one for generating and attaching to project .buildinfo, and one for verifying
3. only root project of multi module should have .buildinfo

in scenario:

1. download from central .buildinfo
2. look for project source in .buildinfo - it can be artifact or some scm address - so we can retrieve source of code
3. using build-tool and rest configuration about required environment from .buildinfo we can build project
4. finally we can check checksum of produced file based on information from outputs.X

• for step 3 we can add tool like wrapper - - in this case for build we only need setup proper jdk
• step 4 should operate only on information from original .buildinfo and is independent of project tools and environment - compare output of binary file

[hboutemy]

I perfectly understand your feedback: it was exactly what I hoped to do at the beginning, 1 year ago.
But when working on it, I found many concrete implementation and usability issues, that lead to the current situation.
I'll tell you on each item what issues I got: if you find a way to implement what I was not able to do, don't hesitate to propose PRs to maven-artifact-plugin

if you think about rebuild-args simply this information should be required by plugin

What about projects that are reproducible but did not add any buindinfo generation step? We need to support that case.
And what about releases that are reproducible but rebuild-args is wrong? (like "works on release manager machine" but does not work on rebuilder setup, for example)
And the buildinfo spec is not really a strong spec: it's a theoretical spec I defined more than 1 year ago, I used it as a base idea, but you'll see that I had to implement some unexpected things (like multi-module support, that is not defined in the spec). The guy who tried to implement buildinfo for sbt chose to create as many buildinfo files as target artifact. And we don't have yet experience on buildinfo generation for other build tools.
And finally, what about buildinfo format evolution over time, if we rely on data published and that will remain forever immutable on Maven Central?

we need two separate goals, one for generating and attaching to project .buildinfo, and one for verifying

don't hesitate to propose a PR: perhaps you'll see why I did it like I did it, perhaps you'll find a workflow that I could not find

only root project of multi module should have .buildinfo

I would be very very interested in that, but I don't see how to implement it: to me, this would be priority 1 to work with you on trying to implement that, because I know that the current implementation, which is the only way I found to implement it, is very unintuitive and makes usage a lot harder than what we need/expect

download from central .buildinfo

we need to support cases where buildinfo has not been published
(just for clarity: we need to support other repositories than central, like a staging repository or another public one)

look for project source in .buildinfo - it can be artifact or some scm address - so we can retrieve source of code

you'll discover how scm info is not so easy to get from current state: there are so many situations (Git sub directory, Windows rebuild when you are on Linux, tag not defined, ...)

really, your scenario is what I was looking for but found that it was an unreachable dream, at least until now

given the current experience after 1 year of reproducible releases publication and rebuild done to check, perhaps some aspects may be achievable now

[hboutemy]

@slawekjaranowski I created https://issues.apache.org/jira/browse/MARTIFACT-6 issue, and perhaps found a nice idea: please continue the discussion in this Jira issue

[hboutemy]

per-project README created in #80 and list of artifacts added in 04a201b

and #79 has some equivalent prerequisites

this goes in the right direction...