On Tue, Dec 06, 2022 at 11:35:03PM +0100, Tim Duesterhus wrote:
> William,
>
> On 12/6/22 19:40, William Lallemand wrote:
> > I disagree, porting to a new API is not something you would do just
> > before a release, you need to do it progressively if possible, because
> > it could introduce heavy development and sometimes discussions with the
> > library developers and unfortunately that could take time.
>
> I understand now. I thought this was primarily about bumping new patch
> versions, not about testing new feature branches.
>
> Please find a patch attached that will start to run the vtest.yml workflow
> weekly early on Thursday morning, making the results available at the start
> of the Thursday workday.
>
> If that change is working correctly, we should see that the "Generate Build
> Matrix" step outputs "Generating matrix for type 'schedule'." for those
> scheduled jobs. You can then add whatever extra jobs you desire to matrix.py
> by checking for `build_type == "schedule"`, like this:
>
> ssl_versions = [
> "stock",
> "OPENSSL_VERSION=1.0.2u",
> "OPENSSL_VERSION=3.0.0",
> ]
>
> if build_type == "schedule":
> ssl_versions.append("OPENSSL_VERSION=latest")
>
> Best regards
> Tim Düsterhus
>
> Apply with `git am --scissors` to automatically cut the commit message.
>
> -- >8 --
> This will run the vtest.yml workflow weekly on every Thursday morning in
> addition to running on every push.
>
> As the `github.event_name` is passed as a parameter to `matrix.py`, this
> allows
> to run specific jobs (e.g. heavy jobs or unstable ones) only on schedule if
> the
> need arises.
> ---
> .github/workflows/vtest.yml | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/.github/workflows/vtest.yml b/.github/workflows/vtest.yml
> index fb7b1d968a..65892cf6b8 100644
> --- a/.github/workflows/vtest.yml
> +++ b/.github/workflows/vtest.yml
> @@ -10,6 +10,8 @@ name: VTest
>
> on:
> push:
> + schedule:
> + - cron: "37 5 * * 4" # 05:37 UTC on Thursday
>
> permissions:
> contents: read
After discussing with the team it seems like we won't do it this way,
and will only need to condition the "latest" build in the dev branches
in the current CI.
But that's good to know it's doable if we change our mind.
Thanks Tim!
--
William Lallemand
