[PATCH] CI: Don't run Coverity on forks

Andrew Cooper posted 1 patch 2 years, 1 month ago
Test gitlab-ci passed
Patches applied successfully (tree, apply log)
git fetch https://gitlab.com/xen-project/patchew/xen tags/patchew/20220321135828.3158-1-andrew.cooper3@citrix.com
.github/workflows/coverity.yml | 1 +
1 file changed, 1 insertion(+)
[PATCH] CI: Don't run Coverity on forks
Posted by Andrew Cooper 2 years, 1 month ago
By default, workflows run in all forks, but the Coverity token is specific to
us, causing all other runs to fail.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
---
CC: Roger Pau Monné <roger.pau@citrix.com>
CC: George Dunlap <George.Dunlap@eu.citrix.com>
CC: Jan Beulich <JBeulich@suse.com>
CC: Stefano Stabellini <sstabellini@kernel.org>
CC: Wei Liu <wl@xen.org>
CC: Julien Grall <julien@xen.org>
---
 .github/workflows/coverity.yml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/.github/workflows/coverity.yml b/.github/workflows/coverity.yml
index 427fb86f947f..f613f9ed3652 100644
--- a/.github/workflows/coverity.yml
+++ b/.github/workflows/coverity.yml
@@ -8,6 +8,7 @@ on:
 
 jobs:
   coverity:
+    if: github.repository_owner == 'xen-project'
     runs-on: ubuntu-latest
     steps:
     - name: Install build dependencies
-- 
2.11.0


Re: [PATCH] CI: Don't run Coverity on forks
Posted by Roger Pau Monné 2 years, 1 month ago
On Mon, Mar 21, 2022 at 01:58:28PM +0000, Andrew Cooper wrote:
> By default, workflows run in all forks, but the Coverity token is specific to
> us, causing all other runs to fail.
> 
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

Acked-by: Roger Pau Monné <roger.pau@citrix.com>

Albeit I have a suggestion to make this more useful I think

> ---
> CC: Roger Pau Monné <roger.pau@citrix.com>
> CC: George Dunlap <George.Dunlap@eu.citrix.com>
> CC: Jan Beulich <JBeulich@suse.com>
> CC: Stefano Stabellini <sstabellini@kernel.org>
> CC: Wei Liu <wl@xen.org>
> CC: Julien Grall <julien@xen.org>
> ---
>  .github/workflows/coverity.yml | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/.github/workflows/coverity.yml b/.github/workflows/coverity.yml
> index 427fb86f947f..f613f9ed3652 100644
> --- a/.github/workflows/coverity.yml
> +++ b/.github/workflows/coverity.yml
> @@ -8,6 +8,7 @@ on:
>  
>  jobs:
>    coverity:
> +    if: github.repository_owner == 'xen-project'

Since I don't know anything else similar, why not make this a secret,
ie: ${{ secrets.RUN_COVERITY_SCAN }}? So that people could decide to
enable coverity on their own repos if desired.

We would also need to introduce a ${{ secrets.COVERITY_SCAN_PROJECT }}

To allow setting a different project name.

Thanks, Roger.

Re: [PATCH] CI: Don't run Coverity on forks
Posted by Andrew Cooper 2 years, 1 month ago
On 21/03/2022 15:04, Roger Pau Monné wrote:
> On Mon, Mar 21, 2022 at 01:58:28PM +0000, Andrew Cooper wrote:
>> By default, workflows run in all forks, but the Coverity token is specific to
>> us, causing all other runs to fail.
>>
>> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
> Acked-by: Roger Pau Monné <roger.pau@citrix.com>
>
> Albeit I have a suggestion to make this more useful I think
>
>> ---
>> CC: Roger Pau Monné <roger.pau@citrix.com>
>> CC: George Dunlap <George.Dunlap@eu.citrix.com>
>> CC: Jan Beulich <JBeulich@suse.com>
>> CC: Stefano Stabellini <sstabellini@kernel.org>
>> CC: Wei Liu <wl@xen.org>
>> CC: Julien Grall <julien@xen.org>
>> ---
>>  .github/workflows/coverity.yml | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/.github/workflows/coverity.yml b/.github/workflows/coverity.yml
>> index 427fb86f947f..f613f9ed3652 100644
>> --- a/.github/workflows/coverity.yml
>> +++ b/.github/workflows/coverity.yml
>> @@ -8,6 +8,7 @@ on:
>>  
>>  jobs:
>>    coverity:
>> +    if: github.repository_owner == 'xen-project'
> Since I don't know anything else similar, why not make this a secret,
> ie: ${{ secrets.RUN_COVERITY_SCAN }}? So that people could decide to
> enable coverity on their own repos if desired.
>
> We would also need to introduce a ${{ secrets.COVERITY_SCAN_PROJECT }}
>
> To allow setting a different project name.

We wouldn't need a secret here.  We could do it on on the existence of
the PROJECT field.

But if we're doing this, then we also need to make the branch selectable
too via the same mechanism.

~Andrew
Re: [PATCH] CI: Don't run Coverity on forks
Posted by Roger Pau Monné 2 years, 1 month ago
On Wed, Mar 23, 2022 at 11:19:50AM +0000, Andrew Cooper wrote:
> On 21/03/2022 15:04, Roger Pau Monné wrote:
> > On Mon, Mar 21, 2022 at 01:58:28PM +0000, Andrew Cooper wrote:
> >> By default, workflows run in all forks, but the Coverity token is specific to
> >> us, causing all other runs to fail.
> >>
> >> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
> > Acked-by: Roger Pau Monné <roger.pau@citrix.com>
> >
> > Albeit I have a suggestion to make this more useful I think
> >
> >> ---
> >> CC: Roger Pau Monné <roger.pau@citrix.com>
> >> CC: George Dunlap <George.Dunlap@eu.citrix.com>
> >> CC: Jan Beulich <JBeulich@suse.com>
> >> CC: Stefano Stabellini <sstabellini@kernel.org>
> >> CC: Wei Liu <wl@xen.org>
> >> CC: Julien Grall <julien@xen.org>
> >> ---
> >>  .github/workflows/coverity.yml | 1 +
> >>  1 file changed, 1 insertion(+)
> >>
> >> diff --git a/.github/workflows/coverity.yml b/.github/workflows/coverity.yml
> >> index 427fb86f947f..f613f9ed3652 100644
> >> --- a/.github/workflows/coverity.yml
> >> +++ b/.github/workflows/coverity.yml
> >> @@ -8,6 +8,7 @@ on:
> >>  
> >>  jobs:
> >>    coverity:
> >> +    if: github.repository_owner == 'xen-project'
> > Since I don't know anything else similar, why not make this a secret,
> > ie: ${{ secrets.RUN_COVERITY_SCAN }}? So that people could decide to
> > enable coverity on their own repos if desired.
> >
> > We would also need to introduce a ${{ secrets.COVERITY_SCAN_PROJECT }}
> >
> > To allow setting a different project name.
> 
> We wouldn't need a secret here.  We could do it on on the existence of
> the PROJECT field.
> 
> But if we're doing this, then we also need to make the branch selectable
> too via the same mechanism.

Sure, that would be better.

Those don't need to be secrets, but I don't know another way to store
such data in a github project.

Thanks, Roger.