Change CI

[Its-Just-Nans]

Hi @Pr0methean

I think we should change the CI on push

on:
  pull_request:
    branches:
      - 'master'
  push:
    branches-ignore:
      - 'gh-readonly-queue/**'
  workflow_dispatch:
  merge_group:
    types: [checks_requested]

on:
  pull_request:
    branches:
      - 'master'
  push:
    branches:
      - 'master'
  workflow_dispatch:
  merge_group:
    types: [checks_requested]

Also, the CI is hanging with the wasm test right now

Because right now it looks like every zip MR generate two CI jobs

https://github.com/zip-rs/zip2/actions/runs/21114414096/job/60720731094

[Its-Just-Nans]

Because right now it looks like every zip MR generate two CI jobs

We should add --headless flag for firefox

[Pr0methean]

Hi @Pr0methean
Because right now it looks like every zip MR generate two CI jobs

https://github.com/zip-rs/zip2/actions/runs/21114414096/job/60720731094

Doesn't the concurrency-group rule ensure they won't both run? And would if-rules be able to do the same or better, given the need to handle PRs both from branches of this repo and from people's forks of it? Or is there something important I'm not understanding about GitHub Actions or its interaction with the PR lifecycle?

[Its-Just-Nans]

Doesn't the concurrency-group rule ensure they won't both run?

I don't think so, from what I know the concurrency is just "only one job at the same time". But I think jobs are both ran, just one after the other

And would if-rules be able to do the same or better, given the need to handle PRs both from branches of this repo and from people's forks of it?

Hum that's possible but PRs are handled with the on: pull_request: branches:

[Pr0methean]

I don't think so, from what I know the concurrency is just "only one job at the same time". But I think jobs are both ran, just one after the other

When you said "every zip MR generate two CI jobs", I thought you meant a push-triggered workflow run and a PR-triggered workflow run on the same non-master branch of the origin repo. I.e. when the PR was to merge branch X into master, and X was part of our repo already, then we'd get a run caused by the push to X without considering whether it belonged to a PR or not, and also a check on Cargo dependencues. @Its-Just-Nans Could you please enlighten me on whatever I'm misunderstanding?

[Pr0methean]

@Its-Just-Nans Or if you can't do that, then feel free to test the change you're advocating with a workflow that makes its version final, and I'll take a look in the morning assuming Actions has yielded usable results by then.

[Its-Just-Nans]

When you said "every zip MR generate two CI jobs", I thought you meant a push-triggered workflow run and a PR-triggered workflow run on the same non-master branch of the origin repo. I.e. when the PR was to merge branch X into master, and X was part of our repo already, then we'd get a run caused by the push to X without considering whether it belonged to a PR or not, and also a check on Cargo dependencues. @Its-Just-Nans Could you please enlighten me on whatever I'm misunderstanding?

Yes I think this is the case right now, if I look at the "Actions" tab after doing a commit I see

Which are

• DevSkim #3850: Pull request fix: make zip crate safer and more readable #536 synchronize
• CI #5527: Pull request fix: make zip crate safer and more readable #536 synchronize
• Auto-merge PRs from trusted bots #2168: Pull request fix: make zip crate safer and more readable #536 synchronize
• CI #5526: Commit e446783 pushed
• CodeQL chore: release v7.4.0 #628: by Its-Just-Nans

If we look at the Ids, we can see that the CI is launched twice #5526 #5527.
And since it it's the same concurrency group (allowing one at a time) it will be #5526 then #5527. As the fuzz takes 2h, this means that we have the feedback after 4h

I think it's working as described, maybe it's not then we're good, but right now it really feels like the CI is super long

[Pr0methean]

Opened #538 to prevent the double trigger. This also means we won't get a CI run if we push to a non-master branch without a PR, but I don't think we've used any such branch for development in years.