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

[Jiang Xin <worldhello.net@gmail.com>]

On Fri, Aug 27, 2021 at 10:10 AM Jeff King <peff@peff.net> wrote:
>
> On Wed, Aug 25, 2021 at 02:14:43PM +0200, Johannes Schindelin wrote:
>
> > > Yes, this is a solution I also want to try at the very beginning. But
> > > some l10n team leaders may fork their repositories directly from
> > > git/git, and name their repo as "{OWNER}/git".  I want to try another
> > > solution: check existence of file "ci/config/allow-l10n" in branch
> > > "ci-config" using a GitHub API, instead of cloning the ci-config
> > > branch and execute the shell script "ci/config/allow-l10n".
> >
> > I understood that you were trying to imitate what git/git does.
> >
> > The problem, in git/git as well as in your patch, is that this is highly
> > cumbersome to use. Yes, it would be better if there was an easier UI to do
> > what you want to do, but the current reality is: there isn't.
> >
> > The main reason why it is so cumbersome to use is that your chosen
> > strategy scatters the CI configuration so much that it puts a mental
> > burden on the users. I, for one, have no idea what is currently in my
> > `ci-config` branch. And new users will be forced to struggle to set up
> > their fork in such a way that the configuration does what they want it to
> > do.
> >
> > And in this instance, there is not even any good reason to make it hard on
> > the users because most will likely not need that new workflow at all. That
> > workflow is primarily interesting for the l10n maintainers.
>
> Just adding my two cents as the person who created the "ci-config"
> mechanism: yes, it's absolutely horrible, and should be avoided if at
> all possible. :)
>
> Your repo-name solution seems like a quite reasonable alternative.
>
> (I'd still love for there to be a way to selectively disable CI on
> certain branches, but I didn't find another one, short of enforcing
> branch-naming conventions that the whole project must agree on).

Yesterday, I created a new github-action:

    https://github.com/marketplace/actions/file-exists-action

And want to use this action in the "ci-config (l10n-config)" job like
this, but it appears slower than before:

-- snip begins --
jobs:
  l10n-config:
    runs-on: ubuntu-latest
    outputs:
      enabled: ${{ steps.check-repo-name.outputs.matched == 'yes' ||
steps.check-file-exists.outputs.exists }}
    steps:
      - id: check-repo-name
        ... ...
      - id: check-file-exists
        name: Check file in branch
        if: steps.check-repo-name.outputs.matched != 'yes'
        uses: jiangxin/file-exists-action@v1
        with:
          ref: ci-config
          path: ci/config/allow-l10n
-- snip ends --

The execution of the "l10n-config" job will take 4 seconds vs 2
seconds before. This may because the new action
"jiangxin/file-exists-action" loads another VM to execute.

So in patch v3, I will remove the entirely "ci-config (l10n-config)"
job, and use an if condition like this:

-- snip begins --
name: git-l10n
on: [push, pull_request_target]
jobs:
  git-po-helper:
    if: endsWith(github.repository, '/git-po') ||
contains(github.head_ref, 'l10n') || contains(github.ref, 'l10n')
    runs-on: ubuntu-latest
    permissions:
      pull-requests: write
    steps:
      ... ...
--snip ends --

Will check the target repository name first.  If l10n leader has a
fork repository with different repo name, push to a special branch
name, such as "l10n/git-2.34", will also trigger the git-l10n
workflow.

--
Jiang Xin