ci: dry fy

[andreivladbrg]

the code was created entirely with claude. the diff doesn’t seem that big, but if we like it (i do), we can polish it and improve the wording

[smol-ninja]

@andreivladbrg you can review the PR now. There is one thing I am not happy about but can't find a way out of it:

For skipped job, such as test-invariant in airdrops, it shows up as forge-test on the Github actions UI. The reason is that the job.name is only propagated to the Action UI when the CI is run. But if you hover over it, the tooltip shows the correct name. Even on the left side menu bar, it shows the correct name.

---

Few notes:

1. I only added exclude input to invariant and unit since they are the only ones excluded from some repos. You may not like it because its not consistent, but I believe only these two are relevant.
2. I had to add deployFactoriesConditionally in airdrop's fork tests because the bytecode is different from the deployed bytecode due to different forge version.
3. I didn't add other inputs such as runs etc. We can add them when we add other CIs (such as ci-fork, ci-deep) depending on the requirement. There are more rooms for optimisation and dry'ify in the CI that we can do but lets do them later. I have spent entire day making the CIs work and I am now tired with it.

---

Full CIs:

1. https://github.com/sablier-labs/lockup/actions/runs/19115799872
2. https://github.com/sablier-labs/lockup/actions/runs/19115799853
3. https://github.com/sablier-labs/lockup/actions/runs/19115799852
4. https://github.com/sablier-labs/lockup/actions/runs/19115799850

[andreivladbrg]

thanks for taking the time to update them. working with the CI isn’t the friendliest task - it looks good overall. just one thing: would it be possible to avoid having duplicate paths?

For example, instead of ci-<name>/test-<something>/test-<something>, use ci-<name>/test/<something>.
This applies to all jobs.

I only added exclude input to invariant and unit since they are the only ones excluded from some repos. You may not like it because its not consistent, but I believe only these two are relevant.

good idea - i like the approach.

2. I had to add deployFactoriesConditionally in airdrop's fork tests because the bytecode is different from the deployed bytecode due to different forge version.

hmm, why does different forge version produces different bytecodes?
what matters are the solc and evm versions, which are the same

3. I didn't add other inputs such as runs etc. We can add them when we add other CIs (such as ci-fork, ci-deep) depending on the requirement. There are more rooms for optimisation and dry'ify in the CI that we can do but lets do them later. I have spent entire day making the CIs work and I am now tired with it.

alright, we can add them later

[smol-ninja]

For example, instead of ci-<name>/test-<something>/test-<something>, use ci-<name>/test/<something>.

I think its possible. Let me try.

hmm, why does different forge version produces different bytecodes?

Because it changes formatting of the source code? I am sure the bytecode is different because it only fails with the latest version.

[andreivladbrg]

Because it changes formatting of the source code? I am sure the bytecode is different because it only fails with the latest version.

hmm, still, i believe it should produce the same bytecode

[smol-ninja]

@andreivladbrg its not possible to choose the full-name of our choice. Its how GH UI renders it. The best I could do it to show it as ci/test-fork/Fork Tests

I chose ci as the first string because the title is CI Utils

[andreivladbrg]

@andreivladbrg its not possible to choose the full-name of our choice. Its how GH UI renders it. The best I could do it to show it as ci/test-fork/Fork Tests

I chose ci as the first string because the title is CI Utils

alright, the change looks good, could you approve the PR?