Skip to content

ADBM-2937: Fix pgbackrest doc test on RH8#101

Merged
GirgerS merged 2 commits into2.54-cifrom
ADBM-2937
Mar 5, 2026
Merged

ADBM-2937: Fix pgbackrest doc test on RH8#101
GirgerS merged 2 commits into2.54-cifrom
ADBM-2937

Conversation

@GirgerS
Copy link

@GirgerS GirgerS commented Feb 25, 2026

The az tool used to create the bucket now requires an API version greater than what Azurite supports. This may be a mistake on their part (but has not resolved after a day) or may indicate that Azurite is no longer actively supported.

Either way, for now it is easiest to suppress the version check so CI builds can proceed. Other corrective action can be taken later as needed.

(cherry picked from commit b52ebe1)

Changes compared to the original commit:

  • Our branch got a cache mismatch issue. It wasn't observed on the
    upstream because results of the build-package test depend on the project
    version specified in the src/version.h. If the version has the
    'dev' suffix, a special code path will be chosen, modifying the test file.

    It doesn't seem that we can easily change the version though,
    as there is other logic bound to it. Instead, just update the cache.


Use archive yum repos to get PostgreSQL 13.

@GirgerS
Copy link
Author

GirgerS commented Feb 25, 2026

Mentioned code path. It seems to be specific for Debian/Ubuntu.

dkovalev1
dkovalev1 previously approved these changes Feb 25, 2026
@bandetto
Copy link
Member

If the version has the 'dev' suffix

'PROJECT_VERSION' seems to be hardcoded in a header file. Why it appears to have 'dev' suffix?

@GirgerS
Copy link
Author

GirgerS commented Feb 26, 2026

If the version has the 'dev' suffix

'PROJECT_VERSION' seems to be hardcoded in a header file. Why it appears to have 'dev' suffix?

It might be misleading wording from me. If the version has the dev suffix, one of the test files is modified to exclude --cache-only flag, so the command can be executed in the case of cache mismatch. Our branch doesn't have this suffix, so the test is forced to take results from the cache. And since the command itself was modified, there was no cache entry for it.

Currently there is a dev version on the upstream. And as you can see, we have a regular version. Seems like the 'dev' suffix is set when a version is still in development, and there is no stable releases for it yet.

@dkovalev1
Copy link

Should the appearance of azurite-blob here and here be updated as well?
Why it was not detected by the tests?

@dkovalev1 dkovalev1 self-requested a review February 27, 2026 05:28
@dkovalev1
Copy link

one of the test files

which one?

so the command can be executed in the case of cache mismatch

which command?

If the version has the
'dev' suffix, a special code path will be chosen, modifying the test file.

Please provide specific details regarding it.

@GirgerS
Copy link
Author

GirgerS commented Mar 2, 2026

one of the test files

which one?

so the command can be executed in the case of cache mismatch

which command?

If the version has the
'dev' suffix, a special code path will be chosen, modifying the test file.

It is basically a description of this logic, and there was a link to it somewhere above. When building package for Debian/Ubuntu, this file is fetched and then used inside debuild. By default it runs doc.pl with --cache-only property, which is overwritten by the upstream.

@GirgerS
Copy link
Author

GirgerS commented Mar 2, 2026

Should the appearance of azurite-blob here and here be updated as well? Why it was not detected by the tests?

Regarding the first link, yes, seems like we should change it. It is used when running doc.pl on RHEL. I'm not sure if it would've caused an error or not, because when running pgbackrest/test/test.pl --vm=rh8 --build-package` locally, the test failed even before it build-package.log. I'll test it a little bit more.

The second one is more complicated. The short answer: because it works either way. This command belongs to the regression test suite, and as you can see from here, it is not affected.

It is not the azurite-blob that is failing, but a subsequent command during documentation build (and don't get confused that they appear in the opposite order, as their blocks are actually evaluated here and here). The patch works because --skipApiCheck flag is global to the whole azurite instance, furthermore it is the only place to specify it.

It matters because the regression test suite doesn't use the aforementioned az command from the azure cli. It creates http requests 'by hand', for example, here.

It is not 'the root case', as it would be great to actually see which particular api has changed, but it doesn't seem that the api reference that the code is relied on has any changes (there are links to it in storage.c). So I am not sure if we want to dig even deeper.

As a side note, it also seems that we ignore the azurite response most of the time.

@GirgerS
Copy link
Author

GirgerS commented Mar 2, 2026

Should the appearance of azurite-blob here and here be updated as well?
Why it was not detected by the tests?

And almost forgot to mention, regular doc builds are not --cache-only. They go through ci.pl -> release.pl -> doc.pl.

The az tool used to create the bucket now requires an API version greater than what Azurite supports. This may be a mistake on their part (but has not resolved after a day) or may indicate that Azurite is no longer actively supported.

Either way, for now it is easiest to suppress the version check so CI builds can proceed. Other corrective action can be taken later as needed.

(cherry picked from commit b52ebe1)

Changes compared to the original commit:
- Our branch got a cache mismatch issue. It wasn't observed on the
  upstream because results of the build-package test depend on the project
  version specified in the src/version.h. If the version has the
  'dev' suffix, a special code path will be chosen, modifying the test file.

  It doesn't seem that we can easily change the version though,
  as there is other logic bound to it. Instead, just update the cache.
@GirgerS
Copy link
Author

GirgerS commented Mar 2, 2026

Well, rh8 build is broken again. And not as a result of our changes, as the draft branch fails too.

@dkovalev1
Copy link

perhaps we need to understand the reason for a failure. It might be unrelated, in this case it will be another task and PR.

@GirgerS
Copy link
Author

GirgerS commented Mar 3, 2026

perhaps we need to understand the reason for a failure. It might be unrelated, in this case it will be another task and PR.

Looks like yum has moved PostgreSQL 12 to archive repo https://yum.postgresql.org/news/pg12-end-of-life/

@GirgerS
Copy link
Author

GirgerS commented Mar 3, 2026

Looks like yum has moved PostgreSQL 12 to archive repo https://yum.postgresql.org/news/pg12-end-of-life/

New commit is added to fix it. PostgreSQL 12 is already fetched from archive repos, so get 13 from them too. Test branch also passes all tests after this change.

@GirgerS GirgerS merged commit a4b801c into 2.54-ci Mar 5, 2026
15 of 16 checks passed
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.

4 participants