Create new build (continuous/latest) that updates after each commit

[ryan]

s/nightly/continuous/ Why nightly builds? Why not continuous builds? Delivering the very latest changes to beta testers through the standard WP update system is powerful and beautiful and easily done. Start with shortening the nightly build cron interval. During beta I'm asking for manual nightly build bumps several times a day so that beta testers can stay up-to-date with brisk development without having to do localhost installs, setup xip.io, svn up, and so on. Continuous testing for continuous development with one-tap update and rollback.

So, can we reduce that interval down to an hour for trunk nightlies? Does the nightly script handle two builds running at the same time gracefully? Is an hour enough padding to avoid overlapping runs? Corrupting the nightly would be bad for beta tester plugin users getting automatic nightly builds. My hope is to approach continuous builds with automated crash testing and notification.

[ryan]

Lots has landed in trunk since the last nightly. I could be testing right now instead of waiting for the next nightly.

[samuelsidler]

I'm changing this ticket a bit.

I think we need to create a new build, let's call it "latest.zip" for the purposes of this comment.

A nightly build – that is, every 24 hours – is important for regular testers that are running WordPress on their site, using the Beta Tester plugin, and want to keep up with changes on a regular basis. There's a limit to how frequent the build can be before it's no longer tenable for someone to use it on their site.

Conversely, a build that is generated after each commit – latest.zip – is important to testers who want to test WordPress frequently. These testers likely aren't using WordPress on their site, but are using it locally and don't want to run from source (svn/git) for whatever reason.

--

There are clearly different use cases and I think it's important to have both builds.

So, let's create a new build, latest.zip, that is built after each commit (or some other really low frequency like 5 minutes). Furthermore, let's get latest.zip added as an option to the Beta Tester plugin so anyone can use it. That should fix this ticket and keep both use cases in place.

[dd32]

Just voicing my opinion - I don't think there needs to be a nightly AND a latest zip.

Assuming that there's been a commit since a site last performed a background update:

• Someone who updates to a nightly zip does it once a day at present
• Someone who were to update using the proposed latest zip would do it twice a day

If they weren't using background updates, it'd be on-demand for both groups.
In the event there hasn't been a commit, neither of those background update scenario's would get updated, and only the on-demand manual updates kick in.

The cross-over between those two groups is large enough that catering to both isn't useful and only makes things more complex.
If someone doesn't want to be able to update to trunk continuously, or doesn't want the autoupdate running twice a day, can easily be solved using a technical solution such as "Only update every 24hrs" within a plugin.

In other words:

• I think we should just increase how many times a day we build the nightly builds.
• We should just rename "nightly" to something else if we really want to be specific as to the content of the file.

[dd32]

Let's increase the frequency that the "nightly" is built at.

If we can't do post-commit, maybe hourly would suffice?

[pento]

Continuous building works for me. If it happened as a post-commit hook on core.svn, it'd be invisible for all practical purposes.

The build script might need some sort of locking support, to ensure it's only doing one build at a time.

[dd32]

Replying to pento:

The build script might need some sort of locking support, to ensure it's only doing one build at a time.

If it was done as a post-commit of core.svn, it'd be easy as each commit is processed sequentially, and it would block processing the next update until that 'nightly' had been built.

[pento]

Oh, I forgot that post-commit was synchronous. Nevermind, then. :)

As it's just generating a single zip, the script is pretty quick. I don't mind it adding some extra wait time before processing the next commit.

[dd32]

One thought that came up, was that using a post-commit hook does mean that, say commit [123456] has a fatal error (maybe a missing file?), and that's fixed in [123457], there'll be a period of time where the nightly release (Which a site may update to) causes a fatal on the site.

The 'normal' way would be to use a CI/CD pipeline, where either Travis builds a "nightly" release and pushes that back over to WordPress.org or pings a webhook to say "Revision 1a2b3c4d is a Go! Rebuild the nightly". The downside of a webhook however is that we test with develop.git but build nightlies from core.svn so it'd have to convert the githash back to a develop.svn commit which would then need to convert that into a core.svn commit number. Having Travis build the nightly might be an option though.

Another option that's a little more convoluted, would be to rebuild the nightly every hour, but trunk only rebuilds automatically when Travis Master is Green (There might still be some off-by-ones here, or when Travis is running behind, etc)

[pento]

The webhook could still work. We can extract the build.svn commit number from the git-svn-id (​example).

Converting that to the corresponding core.svn commit would probably need to be brute-forced, though. The build script would have to take the build.svn commit number, and rewind through core.svn until it finds the ​matching commit.

[dd32]

Replying to pento:

The webhook could still work. We can extract the build.svn commit number from the git-svn-id (​example).

Yup, that's what I was thinking. There's the highly-unlikely possibility that Travis finishes faster than the core.svn sync, which would cause issues, but is rather unlikely :)

[pento]

Yah, it's unlikely, but possible. We could throw an error to Slack in that event, then someone can re-run the Travis job that triggers the build, once it's ready.

This could also be used to trigger release builds, too. I would want to see appropriate checks for that, though. Particularly with auto-updates coming, it shouldn't be possible for one committer to trigger an update rolling out.