[FFmpeg-devel] [PATCH] forgejo/workflows: add initial rudimentary CI

[Timo Rothenpieler]

On 7/22/2025 12:17 AM, Michael Niedermayer wrote:
> On Mon, Jul 21, 2025 at 06:37:06PM +0200, Timo Rothenpieler wrote:
>> It runs basic fate with no special dependencies enabled on x86_64 and
>> aarch64.
>> ---
>>   .forgejo/workflows/test.yml | 39 +++++++++++++++++++++++++++++++++++++
>>   .gitignore                  |  1 +
>>   2 files changed, 40 insertions(+)
>>   create mode 100644 .forgejo/workflows/test.yml
>>
>> diff --git a/.forgejo/workflows/test.yml b/.forgejo/workflows/test.yml
>> new file mode 100644
>> index 0000000000..f9e032b78c
>> --- /dev/null
>> +++ b/.forgejo/workflows/test.yml
>> @@ -0,0 +1,39 @@
>> +on:
>> +  push:
>> +    branches:
>> +      - master
>> +  pull_request:
>> +
>> +jobs:
>> +  run_fate:
>> +    strategy:
>> +      fail-fast: false
>> +      matrix:
>> +        runner: [linux-amd64,linux-aarch64]
>> +    runs-on: ${{ matrix.runner }}
>> +    steps:
>> +      - name: Checkout
>> +        uses: actions/checkout at v4
>> +      - name: Configure
> 
>> +        run: ./configure
> 
> If you want to maximize coverage and maximize speed:
> dash ./configure
> --enable-gpl
> (--enable-nonfree)

The builds aren't ever distributed, so --enable-nonfree is a good call.

> --enable-version3
> --cc='ccache gcc' (or clang)

I don't fully trust ccache to not cause spurious issues.
Gentoo stopped accepting bug reports if ccache was involved and it 
wasn't reproduced without it.
The builds are speedy enough that a full build each time doesn't seem 
too horrible.

I'd rather just add more runners if we ever run into capacity problems, 
which I honestly don't see happening anytime soon.

> --assert-level=2
> --tempprefix=somebasepaththatcanbeusedforcreatingtemporaryfiles

If I understand this right, all it does is use a fixed prefix in /tmp 
instead of just calling mktemp?
I don't immediately see the benefit of that, speed wise.

> --enable-whatever-is-insalled

Yeah, I intend to use the images with tons of deps which I already 
build, either directly or by spinning off some FFmpeg specific fork of them.
And then we need to decide on what makes sense to enable on CI.

> no more comments from me, patch can be applied once everyone is happy
> 
> thx
> 
> [...]
> 
> 
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".