Allow PROJECT_YEAR override

[jasp00]

PROJECT_YEAR depends on build time, which is a problem with reproducible builds. This patch allows the year to be set on configure. This solution is needed until a bot includes the information in the source tree.
This patch allows to use information from the folder release-info, which will come from a tarball generated in the Travis build. The command to build lmms-VERSION-release-info.tar.gz is make release-info and requires Git.

[tresf]

@jasp00 this is good to merge but can you please explain the problem a bit more? I'd expect the year to only change if a subsequent build was fired between December 31st and January 1st. Is that the edge-case we are coding for here?

[tresf]

Answering my own question... https://wiki.debian.org/ReproducibleBuilds/About, merging.

[tresf]

@jasp00 would it make more sense to remove the dynamic value altogether and just offer this information in the version block?

[jasp00]

I will set up a Cron job that will update the year in the version block, and keep CONTRIBUTORS up-to-date (#2914). The commit author will be LMMS maintenance account <noreply@lmms.invalid>, which does not appear as a contributor. This may be triggered by a webhook in the future.

[tresf]

The commit author will be LMMS maintenance account noreply@lmms.invalid, which does not appear as a contributor. This may be triggered by a webhook in the future.

Please use lmms.service<at>gmail.com for service tasks.

I will set up a Cron job that will update the year in the version block, and keep CONTRIBUTORS up-to-date (#2914).

I'm not sure I understand the point of this. If you want 100% reproducible builds, we need to make these items static per-release, right? (e.g. the CONTRIBUTORS listing for 1.1.3 will always only be the only contributor listing for 1.1.3, same for PROJECT_YEAR, etc?)

Perhaps we take a step back and make the scripts which populate these fields pull from the last tagged release information rather than blindly pulling a date from the OS or the contributor listing from the upstream repository.

[jasp00]

we need to make these items static per-release, right?

Right.

Perhaps we take a step back and make the scripts which populate these fields pull from the last tagged release information

I am not sure if I get the idea, but I do not think pulling from the last tag will work, because the information is needed before tagging. May I upload an update-relase-info script that should be run just before making the release?

[tresf]

because the information is needed before tagging

When we release (e.g. 1.3.0, 1.3.1) stable, each will be triggered by by a Travis-CI script which has access to the git information.

From what I understand, reproducible builds will break when the underlying data changes, but if we can extract the timestamp information from the latest commit, it should be pretty solid.

[jasp00]

When we release (e.g. 1.3.0, 1.3.1) stable, each will be triggered by by a Travis-CI script which has access to the git information.

As far as I understand, the release process goes:

1. Publish the release on GitHub, master is tagged and the "source code" files are deployed.
2. Travis CI detects the new tag, builds and deploys the Windows installers. Travis clones to a depth of 50 commits by default, thus the contributors' information is not available.
3. The Mac installer is built in an older environment and manually uploaded.

Is this correct?

From what I understand, reproducible builds will break when the underlying data changes, but if we can extract the timestamp information from the latest commit, it should be pretty solid.

The most recent commit, which may not be the latest. That timestamp information should be in the tree to be included in the "source code" file. A script should be run to update this information (contributor list and project year) just before the release is published.

[tresf]

I'm not sure about (50 commit depth limitation in) bullet 2 above. The rest is correct.

Why a script to touch source? What's wrong with letting CMake/Bash git command do it? Am I missing something?

[jasp00]

I'm not sure about (50 commit depth limitation

This can be configured.

What's wrong with letting CMake/git command do it?

Nothing, let us use make release-info.

[tresf]

git show -s --format=%ci

Outputs:

2016-08-18 10:09:13 -0400

So PROJECT_YEAR should be able to be parsed with relative ease.

[jasp00]

Now the information from Git history is generated with make release-info. This step should be integrated in Travis CI. This method means packagers need to download two tarballs instead of one, but it is easier for the project.

[tresf]

I still don't get the problem with just creating these at build time.

[jasp00]

The information will be generated as part of the deployment by Travis CI, after the build. It cannot be created at build time because the Git log is missing when building from the source tarball and from a shallow repository, like Travis does.

[tresf]

It cannot be created at build time because the Git log is missing when building from the source tarball

Fine, we bundle a default one then. We should add a commented disclaimer to it that the information is a snapshot and may be outdated.

and from a shallow repository, like Travis does.

Can't we simply shim an unshallow into our tagged release scripts?

http://stackoverflow.com/questions/6802145/convert-shallow-clone-to-full-clone

[jasp00]

Fine, we bundle a default one then. We should add a commented disclaimer to it that the information is a snapshot and may be outdated.

This is one reason why a bot maintainer would be helpful. It would keep the information up-to-date and the disclaimer would not be needed.

Can't we simply shim an unshallow into our tagged release scripts?

The idea was to unshallow if TRAVIS_TAG is set, but bundling updated release information makes this unnecessary.

[tresf]

The idea was to unshallow if TRAVIS_TAG is set, but bundling updated release information makes this unnecessary.

I strongly feel these are two separate items. One allows reproducible builds always without any build additional bundling scripts, the other provides a near-immediately outdated copy of authors. No one has ever asked us to have a better author's list and we could even remove the tab if the file is empty. I'm not even sure why this screen exists. Firefox doesn't do this. Gimp doesn't do this.

[jasp00]

Firefox doesn't do this.

Firefox has about:credits.

I'm not even sure why this screen exists.

Should CONTRIBUTORS be dropped?

PROJECT_YEAR could be updated manually along with the project version.

[tresf]

about:credits is hidden from the GUI by default so that is a good comparison from a code perspective but not a good comparison from a UI perspective. The about dialog doesn't have this info.

I feel we should continue updating these automatically. If reproducible builds are the only issue, we handle that downstream by having saner fallback information (or by abolishing the information) rather than making build bots.

Is there a chance we can get build year from the filesystem? Does git the tarball preserve the timestamp of e.g. CMakeLists.txt?

[tresf]

And if we do decide to use build bots, we can leverage lmms.io. Lukas has a nice crontab system he setup that can do the automation tasks for us.

https://github.com/LMMS/lmms.io/tree/master/cron

[jasp00]

How should the fallback information be pushed? Automatically by a bot or running make release-info manually right before the release?

Is there a chance we can get build year from the filesystem?

The files may be patched by packagers, changing timestamps.

we can leverage lmms.io.

Does lmms.io have push permission and git?

[tresf]

The files may be patched by packagers, changing timestamps.

Certainly there are files that naturally won't receive patches, such as .gitignore or something that distro's fetching tarballs wouldn't care or fuss much about.

Does lmms.io have push permission and git?

It's a full-blown Ubuntu 12.04 server, so it can. We have tokens and passwords on it for other things, it wouldn't be out of the ordinary, we'd just have to configure SSH for the person configuring this. We use public key authentication all SSH users, currently myself, @Umcaruje and @Lukas-W can grant access. Transiflex currently uses lmms.service@gmail.com; The service account was created for these types of things. We can also configure email to send out if the job fails, if we feel so inclined.

[jasp00]

Now this request prepares the files to be updated by maintenance tasks in LMMS/lmms.io#198.

[tresf]

I still fail to understand the need for the complexity of this all. Just strip out contributors when git's not available, make contributors tag-specific and lastly have a sane fallback for PROJECT_YEAR so reproducible builds happen. Adding a full blown crontab for updating year seems like overkill unless we have a solid demand for a commit bot elsewhere.

[jasp00]

I still fail to understand the need for the complexity of this all.

The goal is to achieve reproducible builds. The problem is to include the project year and list of contributors for the release.

If there is no need to include project year and contributors, then there is no problem. This means that the package in Debian-like distros and the Linux package from Travis CI will not ship this information. Would this be acceptable?

Adding a full blown crontab for updating year seems like overkill unless we have a solid demand for a commit bot elsewhere.

The idea is to replace the cron job with a webhook. The bot would not only update a year. It would update a year, update the contributors, remove executable bits, optimize PNG images, format code, etc.

[tresf]

This means that the package in Debian-like distros and the Linux package from Travis CI will not ship this information.

Travis should be just fine.

In regards to the Debian-based distributions, I think I see your concern... if the "stable" information is strictly based on the VCS and the VCS is not part of the tarball, the whole concept breaks because the tarball knows nothing about the VCS.

A build bot is going to have complexity problems. First problem is the bot must be triggered sanely or alternately run at reasonable intervals (each commit, each release, daily, etc). The downside to this approach is 1. The build bot must live somewhere. 2. If the build bot only fires on stable releases, the commit will come in too late. It will be HEAD+1, which won't be part of the tarball for e.g. 1.2.0-stable. There may eventually be a good reason for using a build bot, I just strongly feel that PROJECT_YEAR and CONTRIBUTORS are not worth the effort.

So I think we have a situation where we need to go back to using a text file (or a header, etc), write it to data and just ask the devs to commit it occasionally. That way the tarball has the pertinent information without convoluting the process.

[jasp00]

just ask the devs to commit it occasionally.

There is no need to ask this. I can run a bot if lmms.io is not appropriate. Pulling hourly is no big deal; however, I cannot promise full availability. A webhook would help, but it looks like regular users cannot set one up.

[tresf]

There is no need to ask this.

We wouldn't ask. We just wouldn't put it into the gitignore and any git commit -a users would pick it up and it would come in naturally. Unless you're worried about merge conflict, it's simpler.

A robot is fine too, it's just something that one would have to monitor to know if it's working. If the devs commit these files occasionally, it will be obvious and they can make the choice each time to leave it or update it.

[jasp00]

We just wouldn't put it into the gitignore and any git commit -a users would pick it up and it would come in naturally. Unless you're worried about merge conflict, it's simpler.

You said it, merge conflict. On the other hand, this changes would clutter pull requests. Let us put the burden on the bot developers and keep a simple workflow for LMMS developers. I will make the bot when I have some spare time. It will be controllable through a wiki page.

[tresf]

Can you expand on wiki controllable?

[jasp00]

Besides documenting the bot, the wiki page will have a task list with enabled and disabled tasks. When the bot has pending tasks, it checks which ones are enabled in the page and commits the allowed changes. The page might have additional configuration settings.

[tresf]

Besides documenting the bot, the wiki page will have a task list with enabled and disabled tasks. When the bot has pending tasks, it checks which ones are enabled in the page and commits the allowed changes. The page might have additional configuration settings.

Sounds like we're trying to reinvent Travis.

[jasp00]

Sounds like we're trying to reinvent Travis.

It is a bot too, but Travis cannot write to the repository during the build, right?

[tresf]

Travis cannot write to the repository during the build, right

It should be fully capable of it so as long as we're careful not to recurse.

http://stackoverflow.com/a/18029286/3196753
https://gist.github.com/willprice/e07efd73fb7f13f917ea

[jasp00]

It should be fully capable of it

Nice to know. However, I find issues using Travis:

1. The repository needs to be downloaded each time.
2. Travis builds sometimes break, they are not reliable.
3. The only way to test the system is through commits to the repository, not just pull requests.
4. When testing, Travis may do wrong commits.

[tresf]

The repository needs to be downloaded each time.

That is a good point since Travis truncates the commit history.

Travis builds sometimes break, they are not reliable.

Nothing's 100%; ... "less reliable" would be more accurate but that can be outweighed by 1. Constantly monitored. 2. Common enough for new developers to research. 3. Familiar for existing developers.

The only way to test the system is through commits to the repository, not just pull requests.

To whose standard/who cares? Pull Request are truly close enough. If someone with commit access skips the PR process (happens all the time) chances are they're already in the CONTRIBUTORS file anyway (because how else have they earned the trust to commit to the repo?). The only caveat is that said person may not appear as high in the commit order, but again who really cares? They'll get credit eventually and the existing order is only a ballpark anyway (commit count != project involvement).

[jasp00]

The only way to test the system is through commits to the repository, not just pull requests.

Let me explain again. Any write from Travis to the repository requires the use of the encrypted GH_TOKEN, which is only available when Travis builds because of a merge; it is not available for pull requests. So to test the system, you must commit directly, which pollutes the Git log; then wait for the commit from Travis, which will end up in the log; and last, revert a bad commit, which will be in the log too.

[jasp00]

It could be done with Travis, but it will be more difficult to develop. It is a matter of free time.

[tresf]

@jasp00 thanks for the detailed explanation especially the merge dependency and commit catch-22 scenario and most of all patience.

So this is ready to merge then in favor of LMMS/lmms.io#198. I have some questions surrounding the lmms.io PR and I'll address them directly on the lmms.io pull request.

[tresf]

Merging. Word of caution, any builds created between now and the completion of LMMS/lmms.io#198. will see PROJECT_YEAR=2015. This is intentional so that we have a good first commit with the maintenance job.

[zonkmachine]

Word of caution, any builds created between now and the completion of LMMS/lmms.io#198. will see PROJECT_YEAR=2015. This is intentional so that we have a good first commit with the maintenance job.

@tresf Right, as you mentioned on Discord/#Developer(in October), I missed this and manually bumped the year in d0cd42e. The project year currently shows 2017.

[tresf]

@zonkmachine thanks. Yeah, that's fine. The goal was to make this part of the website automatic changes. I can revert that commit on a forked branch during testing.