Skip to content

[MISC] Update PG version and dual branch configurations #5

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

Merged
merged 2 commits into from
Mar 4, 2025
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions .github/renovate.json5
Copy link
Contributor

Choose a reason for hiding this comment

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

imo we should only have the renovate config on the default branch, since renovate only reads it from the default branch

should the default branch be changed to 16/edge?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Renovate can track multiple base branches eg dragomirp#3 and dragomirp#2

Copy link
Contributor

Choose a reason for hiding this comment

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

yes, but it only reads config from default branch

Renovate always uses the config from the repository's default branch, even if that configuration specifies multiple baseBranches. Renovate does not read/override the config from within each base branch if present.

https://docs.renovatebot.com/configuration-options/

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I'd rather keep the two branches consistent, even if the second renovate config is ignored.

Copy link
Contributor

Choose a reason for hiding this comment

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

I think this is confusing & will lead people to misunderstand the renovate config/apply changes to the renovate config in the wrong place

Also, it makes modifying the renovate config require 2 prs instead of 1

Original file line number Diff line number Diff line change
Expand Up @@ -2,4 +2,5 @@
"$schema": "https://docs.renovatebot.com/renovate-schema.json",
"extends": ["github>canonical/data-platform//renovate_presets/charm.json5"],
"reviewers": ["team:data-platform-postgresql"],
"baseBranches": ["/^*\\/edge/"],
}
4 changes: 2 additions & 2 deletions .github/workflows/release.yaml
Original file line number Diff line number Diff line change
Expand Up @@ -9,7 +9,7 @@ concurrency:
on:
push:
branches:
- 14/edge
- "*/edge"
Copy link
Contributor

Choose a reason for hiding this comment

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

for on: push, I believe GitHub uses the release.yaml from the latest commit on the branch

so I think on 14/edge, this should be 14/edge and on 16/edge this should be 16/edge

Copy link
Contributor Author

Choose a reason for hiding this comment

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

With a wildcard we don't have to maintain a permadiff between 14/edge and 16/edge.

Copy link
Contributor

Choose a reason for hiding this comment

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

I think it could confuse developers into thinking the workflow file only needs to be edited once or thinking that the file applies to branches it doesn't

Also, given that we're diverging the branches, I expect we might diverge the workflow file at some point (e.g. when 14/edge is security only updates, it'll probably stay on an old version of dpw and any migrations for dpw breaking changes in the default branch wouldn't be synced to 14/edge)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

On the other hand, mixing up the permadiff when merging will break publishing. I don't think that the branches are expected to diverge CI wise for the foreseeable future, so I rather keep them as consistent as possible until we have a reason to do a hard split.

Copy link
Contributor

Choose a reason for hiding this comment

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

mixing up the permadiff when merging

I think this would be caught in PR reviews

I think it's more likely that "*/edge" will confuse someone into misunderstanding how the workflows work than the publishing accidentally getting broken

paths:
- snap/**
workflow_dispatch:
Expand All @@ -25,7 +25,7 @@ jobs:
- build
uses: canonical/data-platform-workflows/.github/workflows/[email protected]
with:
channel: 14/edge
channel: ${{ github.ref_name }}
artifact-prefix: ${{ needs.build.outputs.artifact-prefix }}
secrets:
snap-store-token: ${{ secrets.SNAP_STORE_TOKEN }}
Expand Down
2 changes: 1 addition & 1 deletion snap/snapcraft.yaml
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
name: postgresql
base: core22
version: '14.15'
version: '14.17'
summary: PostgreSQL in a snap.
description: |
PostgreSQL is a free and open-source relational database management
Expand Down