Skip to content

Conversation

@pnivlek
Copy link
Contributor

@pnivlek pnivlek commented Sep 18, 2024

This makes a pr build workflow to build and test the code on every PR or push. This is a slight no-op since there's no testing, but I figure it's worth adding anyways since the benchmark also acts as an integration test.

A future improvement would be to actually leave a comment when the benchmark gets 100%(?) worse in a PR, but for now it just runs one.

I've tested the github actions code by pushing to a private hard fork, since forks don't run actions normally.

Makes a pr build workflow to build and test the code on every PR or
push.
@absolutedogy
Copy link
Contributor

Sorry for the late reply, never got a notification.

I would love to have a better CI/CD to give a baseline of releases as I think it's core to making sure the code remains high quality. However, I am less experienced with GH actions compared to other run server solutions, so I am going to do some research to make sure there won't be any weird pricing concerns if I set this to auto run.

Might be a prereq to setup a release tagging procedure to run benchmarks against as I did not put a lot of consideration into the branch layout I want to use yet (although feature and pending release branches is likely what I will go with)

@pnivlek
Copy link
Contributor Author

pnivlek commented Sep 25, 2024

No worries! I purposely didn't remind you of it earlier because it's not really blocking anything else.

I have also not used actions outside of like, one or two personal repos that would never hit any paid limits. From what I can tell, we would get 2000 minutes of runtime per month across the organization. The whole workflow currently takes around 2m25s to run so it should be a while before it runs out at our current rate (800 PRs/pushes to main). Although, as we add the ui/core/stats repositories, we should probably only run benchmarks on tagged commits/commits with a keyword in them.

As far as charging goes, it sounds like we won't be charged and it should cut us off if we hit the limit, but you should definitely double check.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants