ppg:staging: align pgaudit/pgpool with QA fixtures; PERCONA_PG_PATCH_VERSION macro (PG 17.10.2 / 18.4.2) - #14
Merged
Conversation
Percona-QA/ppg-testing expects, for the PPG releases currently pinned in staging (14.23 / 15.18 / 16.14 / 17.10 / 18.4): - pgaudit 1.7.1 on PG 15. staging/15 pinned 1.6.3, which is the PG 14 branch (upstream: v1.7.X targets PostgreSQL 15, v1.6.X targets 14). The value dates from the initial PG 15 import (f838753) and was a copy of the PG 14 tree. PG 14/16/17/18 were already correct. - pgpool-II 4.7.2 on all majors. staging/macros.yaml pinned 4.7.1. Both upstream tags exist. The pgaudit rpm/all.patch is not applied (commented out) and %files globs pgaudit--*.sql, so the 1.7.1 SQL file rename needs no packaging change. The pgpool patches touch src/include/pool.h around line 58 and pgpool.conf.sample-stream; the 4.7.1 -> 4.7.2 diff does not overlap those hunks. Signed-off-by: Ricardo Dias <ricardo.dias@percona.com>
The PG 15 pgaudit package still carried percona-pgaudit14.spec and percona-pgaudit14-rpmlintrc, left over from copying the PG 14 tree. The spec content is major-agnostic (pgmajorversion comes from the PG_MAJOR_VERSION macro), so this is a rename only; it matches the percona-pgaudit<major> naming used by staging/14, 16 and 17. Signed-off-by: Ricardo Dias <ricardo.dias@percona.com>
The percona-postgresql _service in staging/17 and staging/18 hard-coded
the Percona fork patch level (release-<PG_VERSION>.1). Introduce a
PERCONA_PG_PATCH_VERSION macro in each project's macros.yaml and build
the revision as release-%!{PG_VERSION}.%!{PERCONA_PG_PATCH_VERSION}, so
a fork patch release is a one-line macro bump like the other versions.
Set it to 2 on both majors to pick up the new fork tags release-17.10.2
and release-18.4.2. The package version (set_version) stays PG_VERSION
(17.10 / 18.4); the fork patch level is a source revision only, as
before.
While here, point the url at https://github.com/percona/postgres.git:
Percona-Lab/postgres is a 301 redirect to it.
staging/16/tde and devel/18 still follow fork *branches*
(release-16.14, release-18.4) rather than tags and are left unchanged;
staging/14-16 build from upstream tags and have no fork patch level.
Signed-off-by: Ricardo Dias <ricardo.dias@percona.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Aligns the
ppg:stagingcomponent pins with what Percona-QA/ppg-testing expects for the PPG releases currently in staging (14.23 / 15.18 / 16.14 / 17.10 / 18.4), and picks up the new Percona fork patch releases of the server.pgaudit 1.7.1 on PG 15
staging/15pinnedPGAUDIT_VERSION: 1.6.3, which is the PG 14 branch (upstream: v1.7.X targets PostgreSQL 15, v1.6.X targets 14). The value dates from the initial PG 15 import (f838753) and was a copy of the PG 14 tree; QA expects 1.7.1. PG 14/16/17/18 were already on the right branch. Therpm/all.patchis not applied (#%%patch0) and%filesglobspgaudit--*.sql, so the 1.7.1 SQL-file rename needs no spec change. The leftoverpercona-pgaudit14.spec/-rpmlintrcin the PG 15 tree are renamed to the15suffix (content is macro-driven; rename only).pgpool-II 4.7.1 → 4.7.2 (all majors)
QA keys 4.7.2 to the current train on every major. Our patches touch
src/include/pool.haround line 58 andpgpool.conf.sample-stream; the upstream 4.7.1→4.7.2 diff does not overlap those hunks. Note:ppg/17.10-1andppg/18.4-1were released with 4.7.1, so this implies a 17.10-2 / 18.4-2 update release.PERCONA_PG_PATCH_VERSIONmacro; PG 17.10.2 / 18.4.2staging/17andstaging/18hard-coded the fork patch level in the server_service(release-<PG_VERSION>.1). A new per-projectPERCONA_PG_PATCH_VERSIONmacro now builds the revision asrelease-%!{PG_VERSION}.%!{PERCONA_PG_PATCH_VERSION}, set to2on both majors to pick uprelease-17.10.2andrelease-18.4.2.set_versionstill usesPG_VERSION, so package versions stay 17.10 / 18.4. The url is switched fromPercona-Lab/postgres(301 redirect) topercona/postgres.Left unchanged on purpose:
devel/*macros,staging/16/tdeanddevel/18(which follow fork branchesrelease-16.14/release-18.4, not tags), andstaging/14–16(upstream tags, no fork patch level).Resolved values were verified with
percona_obs.common.load_macros()for every staging project. No Python changes;tests/pass (98).