I want to share the pact file from consumer to bitbucket and then provider can use from the same location.
Does anybody implemented this?
Thanks in advance.
It's worth noting that it's very much a non-standard way of doing it and I would highly recommend you don't do it this way (see https://docs.pact.io/pact_nirvana/step_4/). You're going to have to build a lot of the workflows again, and that will require investment in building tooling and coming up with ideas to evolve the contract. At some point, you'll be rebuilding key features the Pact Broker already has and would be better off just running that or using a hosted service like pactflow.io.
So, without a pact broker, you don't get the can-i-deploy tool, versioning, environment management and all of these powerful workflows.
With that said - if you do want to use bitbucket:
you'll need to create a manual process (i.e. script) to upload (from consumer) and download (provider) from bitbucket
You'll only want to upload from CI, so that's easier to control
For provider verification, you really want to do this on a laptop, so you'll need a standard approach for pulling down the correct contract to verify there and on CI. Every team member will need credentials to read from that repo
Pact doesn't have a mechanism to pull from git protocols, but you could potentially add that feature to the languages you need them for
Related
I want to deploy my github project to firebase using github actions and the project id is exposed in the .firebaserc file.
Is it safe for make to commit my code to github with the GCP projectID exposed?
Also, I've tried to search for a work around but it seems not to be a concern.
It depends entirely on what you mean by "safe", and what you are giving up to anyone who knows (or can guess) your project ID.
If your exposed project ID has computing resources allocated to it, and those resources can be discovered by what you provide in source control, and those resources are accessible to the public, then you are on the hook to pay the billing for those resources if they might get used.
If your exposed project ID has any public API endpoints that are not protected by some form of authentication, anyone could possibly discover those endpoints, reverse engineer them, and use them to gain the data that those endpoints could possibly deliver.
Even if you do not expose your project ID, someone could guess it and still do all of the above.
In general, I personally would not put any information related to the identification of my projects in public source control. I would leave that a matter of configuration, to be read from environment variables or git-ignored files that must be provided by the person working on the project. That is the safest and least problematic approach.
However, if you want to sacrifice security for convenience, that's entirely up to you. Just be sure you are comfortable with the ramifications of doing so.
See also: Is it safe to expose Firebase apiKey to the public?
I found PACT in some videos from youtube and looks great and quite interested to start POC for my team.
I've read previous questions and try to follow the examples in Pact-JS, but still had some confusion on very basic stuff, so excuse my noob questions.
1. Which repo do I need to refer as official repo?
I assumed ones under Pact-foundation organization are official, but some links in document usually go to different ones.
2. What do I need and from which repo for all the parts of PACT working?
Consumer/provider.
For the start, I think I need PACT_JS.
github.com/pact-foundation/pact-js
Mock service.
Do I need either pact-node or pact-mock-service-npm, or both as well for mock service?
github.com/pact-foundation/pact-node
github.com/pact-foundation/pact-mock-service-npm
Broker
If I want to use broker, then this will need.
github.com/pact-foundation/pact_broker
I think those 3 are the parts I need to use. Is it correct?
3. If there are multiple teams involved, does 1 shared mock server need/help or not really matter? I'm not clear the benefit of stand alone mock server.
https://github.com/pact-foundation/pact-js is the official top-level JS repo.
a) That's correct:
b) You won't need to explicitly include it soon (I'm in the process of an API uplift which should simplify usage), but currently you will need to pull in pact-node to do provider verification
c) If you want to share via a broker, head to https://github.com/bethesque/pact_broker for details (this is not strictly necessary, but recommended)
You won't need the standalone mock service if you use Pact JS. It is designed to be used in cases where there is no language support for Pact (in this case, JS wraps this under the hood for you)
I would check out the end-to-end example which contains all that you'll probably need, including integration to a Broker.
To start with, I have to say that I am not an oracle developer and I have never used any oracle product. But I have a task in hand to automate Fusion Middleware. I have automated the installation using response files. However, I Am not sure how to create the soa domain and extend it to include soa components.
I am using this document http://docs.oracle.com/cd/E23943_01/core.1111/e12036/toc.htm
(steps 8,9 and 10). MAnually, using the GUI i am able to do it but I need to automate it. I know it can be done via wlst scripts. Does anyone have a sample script as per the documentation?Unfortunately, I dont have much time to understand wlst scripting. Any help would be appreciated.
can any one explain java callout a little help will do.Actually i am having several doubts regarding where to add the expressions and message flow jar and where to add my custom jar.
Can i access the resources/java folder directly and can i use it to store my data?
First, check the docs on apigee at
Customize an API using Java
http://apigee.com/docs/api-services/content/customize-api-using-java
Keep in mind Java Callouts are only supported in the paid, Apigee Edge product, not the free Developer platform.
As you decide how to use Java, you should consider this basic hierarchy of policy management:
Policy Configuration First: Apigee policy configurations are in broad use and therefore tested daily by clients and most performant.
Javascript Callout: For stuff you can't do in a standard policy there is Javascript -- keep in mind this is "Compiled Javascript" which means at the time you deploy your project the JS gets interpreted by the Java Rhino engine and then runs like native code. Very fast, very scalable, and very easy to manage as your code is all in plain text files.
Java: You have to have a pretty compelling reason to use Java. Most common cases are where you have some complex connection that needs to be negotiated with custom encryption schemas or manipulating binary content. While perfomant, it's the most difficult code to manage (you upload compiled jars, so if someone takes over your work, the source code is in a separate place than your deployment bundle), and it's the most difficult to debug in the event of a failure.
To your specific question: All Apigee variables are available in Java and Java gives you pretty much god-like powers on the local server where the code is executed. Keep in mind, Apigee's physical architecture is distributed -- your jar may run on different servers for different API calls, so any persistent data (that you might want to store locally) should really be put into Key Value Map and read as needed. Keep your API development as stateless as possible.
Hope that helps.
Are there scripts for exporting and importing all Apigee Edge objects, such as developers, users, apps, caches, key value maps, etc?
To clarify, it would be nice to have non-runtime objects as a priority vs. the runtime data contained within. E.g., the current content of caches are not as critical as just having the cache object available.
I have released a tool that can be used to retrieve Apigee organization settings. This tool has been in use internally at Apigee for some time, but this is the first time it has been released to the public. It uses the Apigee management API to pull configuration data, and that data to be pulled is configurable. The data is stored in a hierarchical directory structure, which can be archived, explored, or used to compare organizations. It can be used with both the Apigee Edge cloud and on-prem offerings.
A few caveats:
This tool does not retrieve all data from an organization. For example, it does not retrieve API proxies. Use the Apigee management UI or management API to retrieve API proxies.
The tool is composed of a few bash scripts. It has been successfully run on Linux and Mac OS X.
The tool does not write data back into the organization, although the files it retrieves can often be POSTed back to the organization using the management API.
This tool is released as-is. It is not officially supported by Apigee.
Find the tool at the api-platform samples site (https://github.com/apigee/api-platform-samples) in the tools/org-snapshot directory.
There is work planned to provide a tool that will export/import provisional data (such as apps, developer, products). Other aspects of an org's configuration require access to the production Cassandra database, which cannot be given out publicly. We have a provisional tool for in-house use that we are currently hardening. If the consumer tool (when it is available) doesn't provide all of the backup support you need, you will need to log a support ticket for them to run the in-house tool.
There are scripts for importing a set of objects (developers, apps, API products) that work with the sample proxies that you can find on GitHub:
https://github.com/apigee/api-platform-samples/tree/master/setup
For Perl programmers: see also Apigee::Edge on CPAN