[Bug 62617] Honor SOURCE_DATE_EPOCH to allow reproducible builds

[bu...@apache.org]

https://bz.apache.org/bugzilla/show_bug.cgi?id=62617

Jaikiran Pai <ja...@apache.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 OS|                            |All

--- Comment #1 from Jaikiran Pai <ja...@apache.org> ---
Hi Julien,

>> By default, the old behavior is preserved, unless SOURCE_DATE_EPOCH is defined in the environment, in which case it is used as the current date.

I think, the proposed patch might not preserve the current behaviour. Since,
right now, even if the SOURCE_DATE_EPOCH is set in the system where the build
is run, the tstamp task will not use it and instead will use the current time.
With this patch, the behaviour will change in such build files. Maybe it's a
better idea to have an explicitly set attribute (a new attribute) on the task
which will start honouring this environment variable? That way the default
semantics of the attribute can continue to ignore this environment variable
unless explicitly set to honour it. Some attribute like "useSourceDateEpoch".


As for the patch:

-            Date d = new Date();
+            Date d;
+            String epoch = System.getenv("SOURCE_DATE_EPOCH");
+            if(epoch.compareTo("") == 0)
+                d = new Date();

I believe you will need a epoch != null check here. In its current form, this
will lead to a NPE on systems where the environment variable isn't set.
Furthermore, I don't think the compareTo call is required. The "spec" that you
pointed to, in the linked content, explicitly states that the value of such an
environment variable MUST be an integer, so I think you can just try to use it
as an Integer value. If you still want to check if the environment variable
value is empty, then I think epoch.isEmpty() is a better API to use.

-- 
You are receiving this mail because:
You are the assignee for the bug.