Hello everyone, good afternoon, how are you? recen...
# pact-jvm
c
Hello everyone, good afternoon, how are you? recently here at our company we bought pact-flow and we are implementing and assembling the flows and we faced some problems and I would like to know if we can help us? The first moment would be, what is the ideal flow for using and creating contract tests? The second would be: today we have the problem of being able to develop pacts locally using pact-flow but we have the following issue, the api tokens cannot be exposed in the code since we do not know how to do it at this point so that the local development is available using the online broker.
b
Hi @Charlan Bettiol, 1: I don’t think there’s one ideal flow, really. You might want to have a look at this, though: https://docs.pact.io/pact_nirvana 2: if you only run tests locally a simple environment variable should do the trick. Or am I misunderstanding your question?
c
Yes, you understand, but in this case, I didn't want this token to be available to more than one person, in this case, to avoid leaking this token
b
So, why not create one token per user in PactFlow and have everybody store them using the same environment variable?
c
because of the number of licenses, we have more devs than licenses we wanted to keep it centralized
b
So you don’t want tokens to be available to more than one developer but also do not want to pay for more users? (By ‘you’ I mean your team/company, not you personally) If that’s the case I’m sorry man, I can’t (and don’t want to) help as that doesn’t sound right to me.
c
I think I expressed myself wrong in the translation communication, even with individual tokens there is a risk of it being exposed and the pacts becoming available, we wanted some means in which authentication was not through an environment variable or key exposed on the developer's machine
b
Gotcha! No worries :) Have you seen the options here? https://docs.pactflow.io/docs/authentication/main/
Although I think you still need a token anyway to authenticate when uploading and downloading contracts and uploading verification results, but I’ve never used any of these options.
c
Thank you very much, I will read the links you passed, the one on the flow gave a great light, now I will study how to send and collect the pacts, we are trying to develop as much as possible without human interaction, just to write the pacts.
👍 1
m
Thank you very much, I will read the links you passed, the one on the flow gave a great light, now I will study how to send and collect the pacts, we are trying to develop as much as possible without human interaction, just to write the pacts.
you’ll still need them for local provider verification. Each developer that verifies the contract should have their own unique token (read-only) to verify pacts locally without compromising security by sharing credentials - I think this is what Bas was alluding to.
I understand the want to automate as much as possible - of course we recommend this also. For CI, you would use system accounts with their respective tokens.
As for ideal flow - the Nirvana guide Bas linked is great, and this is the corresponding workshop ICYMI: https://docs.pactflow.io/docs/workshops/ci-cd/
👍 2
c
@Matt (pactflow.io / pact-js / pact-go) Good morning Thank you very much for these links, would you have something in java?
m
I don't think so, but the principles are the same. All of our example projects use the principles also
Howtoexamples
s