For a build run in artifactory, exists a tab named "Environment" which contains a section named "System Variables".
Link to image: Environment tab with variables
I need to add some properties there via REST API or artifactoy groovy public api (PAPI).
I managed to create build info with properties (via REST API), but now I need to update it with the properties. Is this possible?
The Environment tab is created according to the build-info JSON deployed to Artifactory using the /api/build REST API. The build-info structure is available at the build-info github project's README file here:
https://github.com/JFrogDev/build-info
When building the JSON you can add properties to it, by adding them to the "properties" section as described in the the above README. This is probably how you added the properties to the build run.
The build-info for a specific build run however is immutable in Artifactory and cannot be modified after it is deployed.
Related
I'm trying to setup multiple environments for my Vue / Firebase Project.
I have two Firebase Projects
1.) Dev
2.) Prod
The project utilizes Stripe Extension which pulls the API Key from an auto-generated file called:
firestore-stripe-payments.env
which contains:
STRIPE_API_KEY=projects/${param:PROJECT_NUMBER}/secrets/firestore-stripe-payments-STRIPE_API_KEY-xxxx/versions/latest
Where xxxx is a random 4 character string.
That line pulls the value of the key from Google Secret Manager.
Let's say Dev is 'dddd'
and Prod is: 'pppp'
The issue is that I can only define either:
firestore-stripe-payments-STRIPE_API_KEY-dddd
or
firestore-stripe-payments-STRIPE_API_KEY-pppp
At first I tried to create a new value within Google Secret Manager simply called:
firestore-stripe-payments-STRIPE_API_KEY
The thought was this should be a simple fix, and it would pull the associated API_KEY for the project currently being used.
but this causes the error:
Error: firestore-stripe-payments: Found 'projects/foo/secrets/firestore-stripe-payments-STRIPE_API_KEY/versions/latest' for secret param STRIPE_API_KEY, but this instance was previously using a different secret projects/fooo/secrets/firestore-stripe-payments-STRIPE_API_KEY-dddd.
Changing secrets is not supported. If you want to change the value of this secret, use a new version of projects/foo/secrets/firestore-stripe-payments-STRIPE_API_KEY-dddd.You can create a new version at https://console.cloud.google.com/security/secret-manager?project=fooo
Also, if there is a better place to ask this question please let me know, couldn't find the 'right' room
For this scenario, could you include a separate env (env.dev) file using the following guidelines
.env # loaded in all cases
.env.local # loaded in all cases, ignored by git
.env.[mode] # only loaded in specified mode
.env.[mode].local
For generating separate keys for each environment, I believe from your example you are using a single Stripe Extension on a single project.
Firebase Extensions can support multiple instances of an Extension per project, this will create a separate "dev" secret for you to use.
Additionally, a separate Firebase project with another "Stripe Extension" installation would be recommended to separate any concerns in development.
Most of our client projects have a very similar starting point:
Pristine AWS account used only for a single environment for this application
GraphQL API and a basic model to start with
A REST API with an OAuth handler endpoint and a generic webhook listener endpoint, each with a corresponding Lambda function (with code for each)
I've created this basic amplify app and I want to create a repo with this general structure as a starting point for future projects. The idea being that I'd copy the contents of the repo when starting a project and build from there.
So I've copied the entire amplify directory over to a new location, removing everything that is in the amplify section of the .gitignore file, and I have a folder structure like this:
My steps to start a new project are:
Create a new directory
Copy the template repo files into this directory
run amplify init
Once I do that, it creates two additional files:
amplify/.config/project-config.json
amplify/team-provider-info.json
Then, I try to do amplify push -- but I get No changes detected.
I'm not even sure if what I'm doing is possible -- I was wondering if anyone else has tried this?
I tried to follow the steps given in the below WSO2 documentation link to customize the APIM management console's interface but the changes don't reflect after restarting the carbon server. Need suggestions on this.
Documentation link: https://apim.docs.wso2.com/en/latest/install-and-setup/setup/advance-configurations/customizing-the-management-console/#!
Steps followed as per documentation:
Copied the org.wso2.carbon.ui_4.6.0.jar from <PRODUCT_HOME>/repository/components/plugins/ to a separate location.
Created a MMP with name org.wso2.carbon.ui_4.6.0_patch and added new css file and image file under the MMP. Copied the template.jsp from the org.wso2.carbon.ui_4.6.0.jar and placed it under this MMP project. Within this jsp file, reference of the new css file was added.
Created one more MMP with name org.wso2.carbon.ui_4.6.0_fragment and within its pom.xml added a plugin to point to the org.wso2.carbon.ui_4.6.0_patch MMP.
Created jars for both the MMPs' using maven and copied them under <PRODUCT_HOME>/repository/components/dropins/.
Restarted the WSO2 APIM server but the changes didn't reflect in the management console (https://localhost:9443/carbon) as given in the documentation.
Please follow the instructions given in documentation [1]. The document that you have pointed out has to be updated.
[1] https://is.docs.wso2.com/en/latest/setup/customizing-the-management-console/#customizing-the-management-console
The question is a follow up to this one: Generate Web.Debug config which could be debugged](Generate Web.Debug.config which could be debugged)
I have defined a transformation for web.debug.config. During compilation I see the following:
Transformed Web.config using C:\data\Main\WebRole\Web.Debug.config into
C:\data\Main\obj\obj\x64\Debug\WebRole.csproj\TransformWebConfig\ [...]
transformed\Web.config.
Checked Web.config in the specified location - it is correct (transformation succeeded)
But when I start the service in the azure emulator I get an alert that
Why does it happen? Looks that incorrect web.config is taken. Where should I specify the location of correct (transformed) file?
The key thing to realise with web.config Transforms (and is mentioned in the answer to your linked question) is that they are only part of the story.
When you build your sources, the transformed web.config file is built into the /obj/ folder, ready for deployment.
It is only the act of deploying your solution somewhere that puts the transformed config file into use - as noted in the docs:
When you deploy the Web application by using the selected build configuration and by using either a deployment package or one-click publish, the Web.config file is transformed according to your specifications.
How are you running the application after you build it? You need to publish or deploy it using one of the built in mechanisms that support web transforms to see those changes on your site.
If you are running the emulator against the original source files, they won't see the transformed web.config file - which is why typically the debug build doesn't have any transforms and you then turn off debugging with your Release build which is then deployed to production.
As you're trying to test this in the emulator you should be able to do the following:
In the Solution Explorer, ensure you've selected a file within the project that runs in the emulator.
From the Build menu, select "Publish [Project Name".
In the Publish Wizard, create a new "Profile" using the "Custom" publish target.
In the "Connection" pane select "File System" as the publish method, and give it a suitable target location.
In the "Settings" pane choose the appropriate configuration (in your case probably "Debug"), and set any other options that you'd like.
Then press "Publish", and the project should be built, and then deployed to the new file location.
You should then be able to start the emulator from this newly published location, which will be using your transformed web.config.
I have found this solution and it works perfectly
https://translate.google.co.il/translate?hl=en&sl=de&tl=en&u=http%3A%2F%2Fwww.sascha-dittmann.de%2Fpost%2FWebConfig-Transformation-im-Windows-Azure-Compute-Emulator.aspx&anno=2
In my SBT plugin I am able to obtain instances of sbt.Artifact via UpdateReport, this comes with a File.
However, for jars, I need the organization that the jar belongs to. This is available in sbt.ModuleID.
How do I get the organization when I have the Artifact?
If you're getting the aritfact from the update report, you should also be able to get the module id. The update report is a nested structure, lining up with your Ivy Configurations. Inside each configuration is a set of Modules, and inside each of those is the set of Artifacts included by that Module (Modules can have more than one artifact, a difference from Maven/Aether).
So, here's example code to grab ALL artifacts form ALL configurations and their ModuleID:
for {
conf <- update.value.configurations
moduleReport <- conf.modules
(artifact, file) <- moduleReport.artifacts
} yield (moduleReport.module, artifact, file)