8 Commits

Author	SHA1	Message	Date
Gary Verhaegen	234db7d8e0	rename build-release.ps1 (#19278) ... With the wrong file name it's never used and Windows builds don't benefit from the shortened release process.	2024-05-28 16:06:27 +02:00
Gary Verhaegen	f752c518e1	[3.1] fix protobuf check (#19046) ... Now that 2.8.4 is published, the branch we compare with is in a subdir and the script needs to deal with that.	2024-04-19 13:32:12 +02:00
Gary Verhaegen	7c83265ef9	[release] faster releases - experiment (#18812) ... When we build a release, it is always a "past" commit - typically, one that has already been tested twice: once when the corresponding PR was run, and then again as a "main"-branch commit. Release branches don't run, but their protection rules enforce linear merges. Either way, we know we're building a _good_ commit, and, assuming our builds and tests are hermetic, testing that commit again when we make a release is a pure waste of time and CPU resources. The other case, where we make an ad-hoc release from a branch that has not been merged, has a similar issue: we do not necessarily want to run the full test suite, because part of the reason we need that commit may be that it doesn't succeed as is. Based on that observation, I wondered what might be the minimal set of things we actually need to build when making a release. This PR is an experiment in trying to find that out.	2024-03-27 12:06:39 +01:00
Gary Verhaegen	0749e7c840	refresh-canton: assume ssh for local use (#18868)	2024-03-26 13:56:13 +01:00
Gary Verhaegen	483bfc9a1c	fix hourly cron: docker (#18830)	2024-03-23 11:08:46 +01:00
Gary Verhaegen	e33114bd4e	[cron] fix daily for subdir move (#18819)	2024-03-22 23:47:52 +01:00
Gary Verhaegen	77e7258ac1	subdir: fix hourly cron (#18826)	2024-03-22 16:12:33 +01:00
Gary Verhaegen	e40aad897f	move to subdir 3.0 (#18520) ... * move most files * update CI configuration	2024-03-22 02:27:46 +01:00