Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix: only renovate github actions in main branch #4348

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

nitrocode
Copy link
Member

what

  • only renovate github actions in main branch

why

  • This will reduce the number of github actions PRs to the main branch

references

@nitrocode nitrocode requested review from a team as code owners March 12, 2024 02:16
@nitrocode nitrocode requested review from lkysow, lukemassa and X-Guardian and removed request for a team March 12, 2024 02:16
Copy link
Contributor

@jamengual jamengual left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1

@GenPage
Copy link
Member

GenPage commented Mar 12, 2024

This would remove PRs against the release branches, and require us to cherry pick updates to them to patch which would cause more work. Maybe we update the renovate config to just auto PR/merge patches to release branches only, and the rest to main?

I've also considered grouping minor patches together to reduce the # of PRs in main.

"matchUpdateTypes": ["minor", "patch"],
"groupName": "all-minor-patch"

I think we should reconsider how we group the packages to more criticality instead of package type and tweak the schedule as branch targets as expected.

release branches -> patches only
main -> major/minor bumps

@nitrocode
Copy link
Member Author

Hmm but do we really need github actions updates in the release branches?

@GenPage
Copy link
Member

GenPage commented Mar 12, 2024

That's open to debate I guess. I feel like there's a benefit to allowing patch updates for dependencies on our release branches and we cut patches. Unless we take the stance of just pinning the dependency versions completely and only bump during minor versions, one-off issues?

@jamengual
Copy link
Contributor

if it makes it easier to cherry-pick patches to release branches then we could disable renovate to release branches, if it does not make it easier ( for releases) then I see a value to patch the release branches to keep them updated

@nitrocode
Copy link
Member Author

nitrocode commented Mar 13, 2024

I'm okay with renovate on release branches. For example, if we maintain a 0.27 and a 0.26 then we should maintain both for golang fixes.

But website dependencies are built off the main branch so those should be exempt.

The github actions prs probably only need to be upgraded on the main branch since they build when prs are merged and the action versions are not part of the github release binary.

Golang dependency updates would be needed on all feature branches since these are part of the github release binary.


Also related but not, unsure why we have a 0.27.x branch and a main branch which releases 0.27.x releases. Seems redundant.

@GenPage
Copy link
Member

GenPage commented Mar 16, 2024

I'm okay with renovate on release branches. For example, if we maintain a 0.27 and a 0.26 then we should maintain both for golang fixes.

But website dependencies are built off the main branch so those should be exempt.

The github actions prs probably only need to be upgraded on the main branch since they build when prs are merged and the action versions are not part of the github release binary.

Golang dependency updates would be needed on all feature branches since these are part of the github release binary.

Agreed, on all counts. Maybe we can clean up the renovate config to organize the PRs around these groupings? I'm tired of the constant daily PRs for single patch bumps on dependencies. It clutters the list of PRs in the repo and the change notes.

Also related but not, unsure why we have a 0.27.x branch and a main branch which releases 0.27.x releases. Seems redundant.

The 0.27.x releases are released from the 0.27.x branch. There are no longer releases from the main branch with the new release setup.

@jamengual jamengual added the waiting-on-review Waiting for a review from a maintainer label Apr 30, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
github-actions waiting-on-review Waiting for a review from a maintainer
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants