facebook/sapling
1
1
Fork 0
mirror of https://github.com/facebook/sapling.git synced 2024-10-06 23:07:18 +03:00
Code Issues Projects Releases Wiki Activity
1891591abc
sapling/eden/scm/tests/test-fb-hgext-pushrebase-pushkey.t

123 lines
3.2 KiB
Perl
Raw Normal View History

mark all tests requiring Python 2 Summary: This diff marks **ALL** mercurial tests requiring Python 2 feature. After you fixes some tests, simply remove the `py2` feature requirement and that tests will be continuously run after your diff is landed. To bypass this feature requirement, run the tests command with `HGTEST_FORCE_PY2=1`. For example: ``` HGTEST_FORCE_PY2=1 buck test //eden/scm/tests:hg_run_tests ``` or ``` HGTEST_FORCE_PY2=1 python run-tests.py ``` ---- Basically this diff are created with the following commands: ``` $ sed -i 's/import feature\(.*\)$/import feature\1\n\nfeature.require(["py2"])/' test-*-t.py $ sed -i '1s/^/#require py2\n/' test-*.t $ ls | grep -P "^test.*(?<\!-t)\.py$" > list && vim -p $(cat list) # manually adding feature requires for these Python tests. ``` (Note: this ignores all push blocking failures!) ignore-conflict-markers Reviewed By: singhsrb Differential Revision: D19655148 fbshipit-source-id: 985e3ccb4010cc559049f1d89f8909bc2d9b5e20
2020-01-31 05:40:49 +03:00
#require py2
tests: use disable treemanifest in place of setconfig Summary: Use `disable treemanifest` in place of `setconfig extensions.treemanifest=!` Reviewed By: quark-zju Differential Revision: D19457678 fbshipit-source-id: 47c8b3c4f4ed5cfc97275ca67afab4a86ffe7f0d
2020-01-20 13:42:49 +03:00
$ disable treemanifest
pushrebase: expose real "old" commit to pushkey hooks if commits were not rewritten Summary: During the ovrsource write rollout today, we ran into an interesting race condition in blobimport (which I'll document elsewhere in more detail), which resulted in Mononoke pushing a commit to master that wasn't a descendant of master (it lacked one commit, which we landed separately). Prior to the push, master was at X here: ``` X <- master | A ``` Then, Mononoke attempted to push (this push is not a pushrebase), but its understanding of master was incorrect, and it though A was master. This would normally be blocked by our hooks to deny non-fast-forward pushed, but unfortunately it turns out hat the push was in fact allowed. This left us with a history looking like this: ``` C <- master | B X |/ A ``` The root cause seems to be that the pushrebase code updates the pushkey data that pushkey hooks end up looking at, even if a pushrebase wasn't performed. This resulted in the hook preventing non-ff pushes allowing the push. Reviewed By: quark-zju Differential Revision: D18208700 fbshipit-source-id: 5b728b42a3324344114979f081454ebf74e276cc
2019-11-04 16:51:58 +03:00
$ setconfig devel.legacy.exchange=bookmarks
Setup
tests: update tests-fb-*.t to use new tinit features Reviewed By: quark-zju Differential Revision: D19457679 fbshipit-source-id: d1010f0d2eee69ecdee5c3feba772bd3684d4cec
2020-01-20 13:42:49 +03:00
$ configure dummyssh
pushrebase: expose real "old" commit to pushkey hooks if commits were not rewritten Summary: During the ovrsource write rollout today, we ran into an interesting race condition in blobimport (which I'll document elsewhere in more detail), which resulted in Mononoke pushing a commit to master that wasn't a descendant of master (it lacked one commit, which we landed separately). Prior to the push, master was at X here: ``` X <- master | A ``` Then, Mononoke attempted to push (this push is not a pushrebase), but its understanding of master was incorrect, and it though A was master. This would normally be blocked by our hooks to deny non-fast-forward pushed, but unfortunately it turns out hat the push was in fact allowed. This left us with a history looking like this: ``` C <- master | B X |/ A ``` The root cause seems to be that the pushrebase code updates the pushkey data that pushkey hooks end up looking at, even if a pushrebase wasn't performed. This resulted in the hook preventing non-ff pushes allowing the push. Reviewed By: quark-zju Differential Revision: D18208700 fbshipit-source-id: 5b728b42a3324344114979f081454ebf74e276cc
2019-11-04 16:51:58 +03:00
$ enable pushrebase remotenames
$ cat >> "$TESTTMP/commit.sh" << EOF
> #!/bin/bash
> cd "$TESTTMP/server"
> hg up -q master
> touch X
> hg debugdrawdag --cwd "$TESTTMP/server" << EOS
> commitX
> |
> master
> EOS
> hg bookmark -fr tip master
> echo committed
> hg log -Gr 'all()' -T '{desc} {bookmark}'
> EOF
$ cat >> "$TESTTMP/hook.py" << EOF
> def log(ui, repo, namespace, key, old, new, **kwargs):
> ui.write_err("log %s %s %s -> %s\n" % (namespace, key, repo[old].description(), repo[new].description()))
> return True # True means block the commit here
> EOF
Set up server repository
$ newserver server
$ setconfig pushrebase.blocknonpushrebase=False
$ setconfig hooks.prepushkey.log="python:$TESTTMP/hook.py:log"
$ drawdag << 'EOF'
> commitA
> EOF
$ hg bookmark -r "$commitA" master
Set up client repository
$ cd "$TESTTMP"
$ clone server client
$ cd client
$ hg up master -q
Set up the client to commit on the server-side when a push happens. This simulates a race.
$ cd "$TESTTMP/client"
$ set config extensions.pushrebase=
$ cat >> $TESTTMP/wrapper.py << EOF
> from edenscm.mercurial import exchange, extensions
> def wrapper(orig, pushop):
> r = orig(pushop)
> pushop.repo.ui.system("bash $TESTTMP/commit.sh")
> return r
> def extsetup(ui):
> extensions.wrapfunction(exchange, '_pushdiscovery', wrapper)
> EOF
Create commit for the client
Push without pushrebase, and check that the hook sees the commit that was actually pushed off of (commitA).
$ cd "$TESTTMP/client"
$ setconfig extensions.pushrebase=!
$ touch C
$ hg commit -Aqm 'commitC'
$ hg log -Gr 'all()' -T '{desc} {bookmark}'
@ commitC
|
o commitA
$ hg push --to master --force --config extensions.wrapper="$TESTTMP/wrapper.py"
pushing rev 24c8a95a9829 to destination ssh://user@dummy/server bookmark master
searching for changes
committed
o commitX
|
@ commitA
remote: adding changesets
remote: adding manifests
remote: adding file changes
changegroup: do not show "(+/- ? heads)" Summary: In an upcoming change we'll replace `cl.heads()` with `repo.heads()`. In changegroup code path the repo can be in an inconsistent state (ex. a bookmark refers to an unknown commit) which breaks `repo.heads()`. Since the whole purpose of the heads calculation is just to show `(+/- ? heads)`, which does not affect any real features, let's just remove it. Reviewed By: markbt Differential Revision: D18366735 fbshipit-source-id: 893be2cec0c32b64a80b3ef4ca65b69f8ed76b27
2019-11-07 21:50:10 +03:00
remote: added 1 changesets with 1 changes to 1 files
pushrebase: expose real "old" commit to pushkey hooks if commits were not rewritten Summary: During the ovrsource write rollout today, we ran into an interesting race condition in blobimport (which I'll document elsewhere in more detail), which resulted in Mononoke pushing a commit to master that wasn't a descendant of master (it lacked one commit, which we landed separately). Prior to the push, master was at X here: ``` X <- master | A ``` Then, Mononoke attempted to push (this push is not a pushrebase), but its understanding of master was incorrect, and it though A was master. This would normally be blocked by our hooks to deny non-fast-forward pushed, but unfortunately it turns out hat the push was in fact allowed. This left us with a history looking like this: ``` C <- master | B X |/ A ``` The root cause seems to be that the pushrebase code updates the pushkey data that pushkey hooks end up looking at, even if a pushrebase wasn't performed. This resulted in the hook preventing non-ff pushes allowing the push. Reviewed By: quark-zju Differential Revision: D18208700 fbshipit-source-id: 5b728b42a3324344114979f081454ebf74e276cc
2019-11-04 16:51:58 +03:00
remote: log bookmarks master commitA -> commitC
remote: pushkey-abort: prepushkey.log hook failed
remote: transaction abort!
remote: rollback completed
abort: updating bookmark master failed!
[255]
Now, do a pushrebase. First, reset the server-side.
$ cd "$TESTTMP/server"
$ hg bookmark -f -r "$commitA" master
Then, pushrebase. This time, we expect the pushkey to be updated
$ cd "$TESTTMP/client"
$ setconfig extensions.pushrebase=
$ hg push --to master --config extensions.wrapper="$TESTTMP/wrapper.py"
pushing rev 24c8a95a9829 to destination ssh://user@dummy/server bookmark master
searching for changes
committed
o commitX
|
@ commitA
remote: pushing 1 changeset:
remote: 24c8a95a9829 commitC
remote: 2 new changesets from the server will be downloaded
remote: log bookmarks master commitX -> commitC
remote: pushkey-abort: prepushkey.log hook failed
remote: transaction abort!
remote: rollback completed
abort: updating bookmark master failed!
[255]
Reference in New Issue Copy Permalink