Re: [PATCH 1/1] ci: new github-action for git-l10n code review
- From
Jiang Xin <worldhello.net@gmail.com>
- Date
- Aug 27, 2021, 02:49 UTC
- Message-ID
- <CANYiYbESO7bvyuRcypmVKvqAdLk5492q5fUPu5ArdCY5PHzFSQ@mail.gmail.com>
- In-Reply-To
- <YShJscwm/jMDOCx5@coredump.intra.peff.net>
On Fri, Aug 27, 2021 at 10:10 AM Jeff King <peff@peff.net> wrote:
Show 36 quoted lines
>
> 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