Обсуждение: pgsql: Force run of pg_upgrade in the build directory in its TAP test
Force run of pg_upgrade in the build directory in its TAP test TAP tests are run from their own directory in the source tree, and in a VPATH build the execution of the pg_upgrade command was leaving behind a file in the source tree, that should be left untouched. In order to avoid this issue, the test moves to PostgreSQL::Test::Utils::tmp_check, so as any files generated by pg_upgrade do not impact the source tree, but the build tree. This has as nice side-effect to make unnessary the presence of such files in pg_upgrade's .gitignore and Makefile. This strategy is similar to psql's test 010_tab_completion.pl, though the reasons behind this choice are different. In passing, fix one misleading test name that was added by 99f6f19. Per discussion with Peter Eisentraut, Andrew Dunstan, Tom Lane, Andres Freund and myself. Discussion: https://postgr.es/m/f80ace33-11fb-1cd3-20f8-98f51d151088@enterprisedb.com Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/15b6d2155375dee2fcba072fffa03c1c8b44656c Modified Files -------------- src/bin/pg_upgrade/.gitignore | 3 --- src/bin/pg_upgrade/Makefile | 3 +-- src/bin/pg_upgrade/t/002_pg_upgrade.pl | 7 ++++++- 3 files changed, 7 insertions(+), 6 deletions(-)
Michael Paquier <michael@paquier.xyz> writes:
> Force run of pg_upgrade in the build directory in its TAP test
This commit removed delete_old_cluster.sh etc. from .gitignore,
but they are still generated in the current directory, so after
running a test in a non-VPATH setup I see
$ git status
...
Untracked files:
(use "git add <file>..." to include in what will be committed)
delete_old_cluster.sh
I suppose it would be too user-unfriendly to generate those scripts
underneath $PGDATA, so don't we need to put back the .gitignore
entries?
regards, tom lane
On Tue, Jun 14, 2022 at 01:23:04PM -0400, Tom Lane wrote:
> I suppose it would be too user-unfriendly to generate those scripts
> underneath $PGDATA, so don't we need to put back the .gitignore
> entries?
delete_old_cluster.sh is generated within tmp_check/ in a non-VPATH
build:
$ cd src/bin/pg_upgrade/ && make check
$ find . -name delete_old_cluster.sh
./tmp_check/delete_old_cluster.sh
$ git grep chdir -- *.pl
t/002_pg_upgrade.pl:chdir ${PostgreSQL::Test::Utils::tmp_check};
Or you have a workflow where you do a "make clean" after running the
tests on a past stable branch? This would leave behind
delete_old_cluster.sh, especially if the cleanup is triggered on
HEAD. With each branch taken in isolation, there is no need for a
.gitignore entry. (FWIW, I just use a worktree these days in my flow
of patching across multiple stable branches.)
--
Michael
Вложения
Michael Paquier <michael@paquier.xyz> writes:
> On Tue, Jun 14, 2022 at 01:23:04PM -0400, Tom Lane wrote:
>> I suppose it would be too user-unfriendly to generate those scripts
>> underneath $PGDATA, so don't we need to put back the .gitignore
>> entries?
> delete_old_cluster.sh is generated within tmp_check/ in a non-VPATH
> build:
Sorry, I wasn't very clear: I'd tested pg_upgrade with a manual
invocation, like "./pg_upgrade -d ...". That used to be OK and
now it leaves junk around. I think it's worth keeping the
.gitignore entries (and I guess the "make clean" rule step too)
so that that approach still works without making a mess.
regards, tom lane
On Tue, Jun 14, 2022 at 08:11:59PM -0400, Tom Lane wrote: > Sorry, I wasn't very clear: I'd tested pg_upgrade with a manual > invocation, like "./pg_upgrade -d ...". That used to be OK and > now it leaves junk around. I think it's worth keeping the > .gitignore entries (and I guess the "make clean" rule step too) > so that that approach still works without making a mess. No big deal to me to add that both the .gitignore entry and the cleanup rule if that's annoying for some. FWIW, I just have some scripts lying around to launch my upgrade commands in isolated paths, pretty much like the TAP tests. -- Michael