Re: [PATCH 1/1] ci: new github-action for git-l10n code review

5 messages, 4 authors, 2021-08-31 · open the first message on its own page

Re: [PATCH 1/1] ci: new github-action for git-l10n code review

From: Junio C Hamano <hidden>
Date: 2021-08-23 21:43:22

Johannes Schindelin [off-list ref] writes:
quoted
For a push event, it will scan commits one by one. If a commit does not
look like a l10n commit (no file in "po/" has been changed), it will
immediately fail without checking for further commits. While for a
pull_request event, all new introduced commits will be scanned.

"git-po-helper" will generate two kinds of suggestions, errors and
warnings. A l10n contributor should try to fix all the errors, and
should pay attention to the warnings. All the errors and warnings will
be reported in the last step of the l10n workflow as two message groups.
For a pull_request event, will create additional comments in pull
request to report the result.
It is a good idea to automate this.

I am a bit concerned that the `ci-config` approach, even if we use it in
the Git project itself, is quite cumbersome to use, though. So I hope that
we can find an alternative solution.

One such solution could be to make the `git-po-helper` job contingent on
part of the repository name. For example:

  git-po-helper:
    if: endsWith(github.repository, '/git-po')
    [...]

would skip the job unless the target repository's name is `git-po`.
Nice.

Can this be made into a matter purely local to git-l10n/git-po
repository and not git/git repository?  I am wondering if we can ee
if the current repository is git-l10n/git-po or its fork and run it
only if that is true.

Thanks.

Re: [PATCH 1/1] ci: new github-action for git-l10n code review

From: Johannes Schindelin <hidden>
Date: 2021-08-24 09:28:24

Hi Junio,

On Mon, 23 Aug 2021, Junio C Hamano wrote:
Johannes Schindelin [off-list ref] writes:
quoted
quoted
For a push event, it will scan commits one by one. If a commit does not
look like a l10n commit (no file in "po/" has been changed), it will
immediately fail without checking for further commits. While for a
pull_request event, all new introduced commits will be scanned.

"git-po-helper" will generate two kinds of suggestions, errors and
warnings. A l10n contributor should try to fix all the errors, and
should pay attention to the warnings. All the errors and warnings will
be reported in the last step of the l10n workflow as two message groups.
For a pull_request event, will create additional comments in pull
request to report the result.
It is a good idea to automate this.

I am a bit concerned that the `ci-config` approach, even if we use it in
the Git project itself, is quite cumbersome to use, though. So I hope that
we can find an alternative solution.

One such solution could be to make the `git-po-helper` job contingent on
part of the repository name. For example:

  git-po-helper:
    if: endsWith(github.repository, '/git-po')
    [...]

would skip the job unless the target repository's name is `git-po`.
Nice.

Can this be made into a matter purely local to git-l10n/git-po
repository and not git/git repository? I am wondering if we can ee if
the current repository is git-l10n/git-po or its fork and run it only if
that is true.
The biggest problem is that there are forks of `git-l10n/git-po` that
accept PRs in their own right. That is what I tried to address by using
just the repository name, without the org/user prefix.

Ciao,
Dscho

Re: [PATCH 1/1] ci: new github-action for git-l10n code review

From: Jiang Xin <hidden>
Date: 2021-08-24 13:36:16

On Tue, Aug 24, 2021 at 5:36 AM Junio C Hamano [off-list ref] wrote:
Johannes Schindelin [off-list ref] writes:
quoted
quoted
For a push event, it will scan commits one by one. If a commit does not
look like a l10n commit (no file in "po/" has been changed), it will
immediately fail without checking for further commits. While for a
pull_request event, all new introduced commits will be scanned.

"git-po-helper" will generate two kinds of suggestions, errors and
warnings. A l10n contributor should try to fix all the errors, and
should pay attention to the warnings. All the errors and warnings will
be reported in the last step of the l10n workflow as two message groups.
For a pull_request event, will create additional comments in pull
request to report the result.
It is a good idea to automate this.

I am a bit concerned that the `ci-config` approach, even if we use it in
the Git project itself, is quite cumbersome to use, though. So I hope that
we can find an alternative solution.

One such solution could be to make the `git-po-helper` job contingent on
part of the repository name. For example:

  git-po-helper:
    if: endsWith(github.repository, '/git-po')
    [...]

would skip the job unless the target repository's name is `git-po`.
Nice.

Can this be made into a matter purely local to git-l10n/git-po
repository and not git/git repository?  I am wondering if we can ee
if the current repository is git-l10n/git-po or its fork and run it
only if that is true.
I have read almost all the github documents on github actions, and
tried to find if I can use a local branch, such as "github-action" to
hold local github-actions, but no locky.

That is to say, the workflow file must be introduced to the master
branch of “git-l10n/git-po”. As "git-l10n/git-po" is a fork of
"git/git", the new workflow should be part of "git/git", and provide a
way to disable it by default.

--
Jiang Xin

Re: [PATCH 1/1] ci: new github-action for git-l10n code review

From: Jean-Noël AVILA <hidden>
Date: 2021-08-30 20:49:53

Le mardi 24 août 2021, 11:27:44 CEST Johannes Schindelin a écrit :
Hi Junio,

On Mon, 23 Aug 2021, Junio C Hamano wrote:
quoted
Johannes Schindelin [off-list ref] writes:
quoted
quoted
For a push event, it will scan commits one by one. If a commit does not
look like a l10n commit (no file in "po/" has been changed), it will
immediately fail without checking for further commits. While for a
pull_request event, all new introduced commits will be scanned.

"git-po-helper" will generate two kinds of suggestions, errors and
warnings. A l10n contributor should try to fix all the errors, and
should pay attention to the warnings. All the errors and warnings will
be reported in the last step of the l10n workflow as two message groups.
For a pull_request event, will create additional comments in pull
request to report the result.
It is a good idea to automate this.

I am a bit concerned that the `ci-config` approach, even if we use it in
the Git project itself, is quite cumbersome to use, though. So I hope that
we can find an alternative solution.

One such solution could be to make the `git-po-helper` job contingent on
part of the repository name. For example:

  git-po-helper:
    if: endsWith(github.repository, '/git-po')
    [...]

would skip the job unless the target repository's name is `git-po`.
Nice.

Can this be made into a matter purely local to git-l10n/git-po
repository and not git/git repository? I am wondering if we can ee if
the current repository is git-l10n/git-po or its fork and run it only if
that is true.
The biggest problem is that there are forks of `git-l10n/git-po` that
accept PRs in their own right. That is what I tried to address by using
just the repository name, without the org/user prefix.

Ciao,
Dscho
Well, I'm in this case, plus my repo is a fork of git/git. 

Would it not possible to formally require the presence of a "dumb" secret to run this rule? 

JN

Re: [PATCH 1/1] ci: new github-action for git-l10n code review

From: Jiang Xin <hidden>
Date: 2021-08-31 01:03:43

On Tue, Aug 31, 2021 at 4:49 AM Jean-Noël AVILA [off-list ref] wrote:
Le mardi 24 août 2021, 11:27:44 CEST Johannes Schindelin a écrit :
quoted
The biggest problem is that there are forks of `git-l10n/git-po` that
accept PRs in their own right. That is what I tried to address by using
just the repository name, without the org/user prefix.

Ciao,
Dscho
Well, I'm in this case, plus my repo is a fork of git/git.

Would it not possible to formally require the presence of a "dumb" secret to run this rule?
It is not supported to use secrets/env in if condition. See this post:

    https://github.community/t/jobs-job-id-if-does-not-work-with-env-secrets/16928

In patch v3, will check both repo name and branch names. See:

    https://lore.kernel.org/git/20210827071320.14183-1-worldhello.net@gmail.com/

--
Jiang Xin
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help