Run builds on push to master branch #550

Closed
opened 2024-11-15 09:53:25 +00:00 by alexvanin · 5 comments
Owner

This repo uses "rebase and ff" strategy to merge pull requests. Two PRs may break master branch if one changes function signature, another use it, and both are merged at one time. All checks will be green, but master branch is going to be broken.

Describe the solution you'd like

The fastest way to find broken master is to build nightly build. Until then we can trigger build job on every push to master branch. And we can notice red cross on a latest commit message.

It seems to me as common practice, see neo-go workflow for example.

Let's discuss it and update trigger for build job it this proposal makes sense.

/cc @potyarkin, @realloc

## Is your feature request related to a problem? Please describe. This repo uses "rebase and ff" strategy to merge pull requests. Two PRs may break master branch if one changes function signature, another use it, and both are merged at one time. All checks will be green, but master branch is going to be broken. ## Describe the solution you'd like The fastest way to find broken master is to build nightly build. Until then we can trigger build job on every push to master branch. And we can notice red cross on a latest commit message. It seems to me as common practice, see [neo-go](https://github.com/nspcc-dev/neo-go/blob/5707bdd1d1d91bd69e34e68fdb857a02ce6d8e6c/.github/workflows/build.yml#L11-L14) workflow for example. Let's discuss it and update trigger for build job it this proposal makes sense. /cc @potyarkin, @realloc
alexvanin added the
discussion
label 2024-11-15 09:53:48 +00:00
Author
Owner

I am against "ff-only" merge strategy, because master break happens quite rarely, and ff-only is going to slow down merge process in my opinion.

I am against "ff-only" merge strategy, because master break happens quite rarely, and ff-only is going to slow down merge process in my opinion.
Member

I was about to suggest "ff-only" when I saw your updated comment

I see no downsides in adding CI runs on push to master and on schedule. Would you like this behavior in frostfs-s3-gw only or across all of services team repos?

~~I was about to suggest "ff-only" when I saw your updated comment~~ I see no downsides in adding CI runs [on push](https://forgejo.org/docs/latest/user/actions/#onpush) to master and [on schedule](https://forgejo.org/docs/latest/user/actions/#onschedule). Would you like this behavior in frostfs-s3-gw only or across all of services team repos?
potyarkin self-assigned this 2024-11-15 10:07:21 +00:00
Author
Owner

Would you like this behavior in frostfs-s3-gw only or across all of services team repos?

Let's do this across s3 and http gateways. Not sure we need schedule runs, on push should be enough.

> Would you like this behavior in frostfs-s3-gw only or across all of services team repos? Let's do this across s3 and http gateways. Not sure we need schedule runs, on push should be enough.
Member

I've added on.push to all workflows, except for DCO checker: there is no PR base ref during push, and adding custom handling for push events seems overkill since we do not allow direct pushes to master anyways. Merge conflicts can not happen in commit messages 😄

See:

I've added `on.push` to all workflows, except for DCO checker: there is no PR base ref during push, and adding custom handling for push events seems overkill since we do not allow direct pushes to master anyways. Merge conflicts can not happen in commit messages 😄 See: - https://git.frostfs.info/TrueCloudLab/frostfs-s3-gw/pulls/552 - https://git.frostfs.info/TrueCloudLab/frostfs-http-gw/pulls/165
Author
Owner

@potyarkin Thanks! Closed.

@potyarkin Thanks! Closed.
Sign in to join this conversation.
No milestone
No project
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: TrueCloudLab/frostfs-s3-gw#550
No description provided.