https://pact.io logo
Join Slack
Powered by
hey! :slightly_smiling_face: any recommendation ab...
# pact-js
m
hey! 🙂 any recommendation about the generated pact files being kept in version control or not? currently my team has that folder on .gitignore and i dont really understand it .. so wanted to check if there are some recommendations on this for best practices. to me, seeing it as a contract, it seems that the generated file should be kept, but would like to check some opinions 🙂
m
It's generally expected to not check-in the files if you use a pact broker
m
ok, but why?
at least im seeing this as a contract that should be kept between different executions (if nothing changed). bit like a snapshot or something similar
y
It can lead to stale interactions and issues merging contents. If you remove a pact test from your codebase, the interaction would remain in your pact contract, that is no bueno
You can check them in if you want, but I would just ensure the pacts folder is cleared prior to any new test execution.
m
and issues merging contents.
because when pact runs, it merges the new test execution to the previous?
y
kinda, you have a named file with consumer/provider name. if you have 3 tests, all with the same c/p name, you will get one pact file, with three interactions.
if you remove one of those tests, you will still have three interactions in your pact file, if you haven’t deleted it prior to the 2nd test run
m
yup yup, that makes sense and i agree with the removal between tests executions while in local. even my local command does something like 
rm -rf pacts && run_pact_tests
but as im seeing this a bit like a snapshot (from jest) not really getting the part of not pushing them and having to generate again in the pipeline to be able to publish. at least im not expecting that a different behaviour would be outputted i might be seeing this the wrong way though
y
not really getting the part of not pushing them and having to generate again in the pipeline to be able to publish.
If you don’t generate them in the pipeline, then the results could be erroneous. you should never pregenerate pact contracts, and publish them from CI from a build that hasn’t ran the tests. the code could have changed from the content in the contract
I get the snapshot bit, you can see it in a diff, you can also see diffs in the pact broker, diffs between distinct versions
m
yeah, that second comment is my mindset
i dont understand how generated contracts would be different in the pipeline though. (as long as I had run them in my local before pushing of course)
y
as long as I had run them in my local before pushing of course
That is manual effort on your part, that you or others might forget. You might not check in the updated files
if you have to caveat it …
m
okok. thank you for the explanation 🙂
y
maybe you can solve that problem with pre-commit hooks, but just worth being aware. I think the TL;DR is local machines are thought to be dirty in terms on the contents, and we trust CI more, and can associate a version with the contract, so we have high confidence on which commit the contract was associated with. and no worries, always happy to chat
🙌 1
💪 1
💯 1
m
and we trust CI more, and can associate a version with the contract, so we have high confidence on which commit the contract was associated with.
actually this makes some more sense to me, thank you for the TL;DR
Open in Slack
PreviousNext
Powered by