I'm using Gitlab CI to deploy TYPO3 projects onto a target server and I'm trying to remove the PackageStates.php from the git repository and generate it on the target server with EXT:typo3_console instead.
But I need to set the TYPO3_ACTIVE_FRAMEWORK_EXTENSIONS environment variable in order to have the necessary system extensions loaded.
How do I set this ENV variable?
What's a good way to store these information in my project to have it available in the deployment process? I could use Gitlab variables but I feel like this information should be included in the git repository.
You don't need to set and use the env variable if you don't want to. You can just require the TYPO3 core extensions you need in any package of your project and typo3_console will take care to populate the environment variable for you as needed during composer install time.
If you want to, you can however still override this env var from command line for individual calls.
EDIT: This feature has been integrated in typo3_console 3.3.0
Related
I'm using GitLab CI Auto DevOps to compile a project based on Maven based in a DinD (docker-in-docker) runner.
CI job start, and buildpack for Maven is correctly detected (based on herokuish).
How can I configure a custom settings file without switching to a custom .gitlab-ci.yml?
I would like to continue using Auto DevOps.
Because maven needs access to a private repository based on Nexus it is convenient to configure a custom settings.xml (and version it with your source code)
The easiest solution is to include a custom settings.xml. This feature was included in the corresponding buildpack used by Auto DevOps some time ago, as you can see in this article from Heroku buildpacks about "Using a Custom Maven Settings File".
So I defined MAVEN_SETTINGS_PATH variable in .gitlab-ci.yml config file:
variables:
- MAVEN_SETTINGS_PATH: ".m2/settings.xml"
Then, included the file settings.xml in the repository.
Avoid to include secrets or another sensible information
When using a private maven repository with credentials
Finally, you can define in Gitlab some variables to be used in settings.xml. Using Gitlab UI or API add variables for the user, password, and repository url, to be included as environment variables from Gitlab into the job. Then you can use it in settingx.xml like ${env.VARIABLE_NAME}
Example of Gitlab-CI configuration file:
include:
- template: Auto-DevOps.gitlab-ci.yml
variables:
MAVEN_SETTINGS_PATH: ".m2/settings.xml"
AUTO_DEVOPS_BUILD_IMAGE_FORWARDED_CI_VARIABLES: NEXUS_REPO_USER,NEXUS_REPO_PASSWORD,NEXUS_REPO_URL
As a final recommendation, you should avoid to use passwords in environment variables, use native methods from your environment for credentials storage is recommended.
I have feature files in cucumber ,for its step definition I am using Ruby-selenium.I am trying to integrate with my local Jenkins but I am unable to do the same.
Any headsup how to proceed
When things about Jenkins, it is mostly about Environment Variables. I recommend you to check if your local env vars are correctly passed to Jenkins.
I am currently trying to get my Jenkins (version 2.35) Jobs for AEM (6.2) author/publishers up and running. In this setup I have Dev, Staging and Production environments. To avoid version controlling my credentials in my pom.xml I have made the use of environment variables in maven (version 3.3.9).
<properties>
<aem.host>localhost:4502</aem.host>
<aem.protocol>http</aem.protocol>
<aem.user>${env.AEM_AUTHOR_USER}</aem.user>
<aem.password>${env.AEM_AUTHOR_PASSWORD}</aem.password>
</properties>
On my local environment I have tested setting those environment variables to the correct and then incorrect values and it behaves as one would think it would.
The thing here is that when I build the Dev Author job on my Jenkins server, it seems to succeed whether the environment variables are set to the correct values or not. It is so weird and at this point I have no clue to what is going on. I am setting the environment variables on the Jenkins server via a simple.
source ~/path/to/file
Where ~/path/to/file would look something like the following:
AEM_AUTHOR_USER="admin"
AEM_AUTHOR_PASSWORD="admin"
Also I should mention that previously to using environment variables in maven I had the AEM credentials directly in the pom.xml just for Dev jobs.
I'm wondering if Jenkins has cached the maven properties thus the credentials and re-setting the environment variables has no effect. I should also mention I have tried re-creating the workspace on each new build to see if it would clear some caching system but no dice.
Is Jenkins or Maven caching my maven properties somewhere that my environment variables are being ignored ?
Has anyone ran into the issue I am describing ?
Should I be using the EnvInject Plugin Jenkins plugin ?
Any help is welcomed.
Thanks,
Nicola
In the case of my Develop Jobs it seems that Jenkins uses some sort of caching system that I wasn't able to clear. Even after deleting the workspace or deleting the cache folder in
/home/jenkins/.jenkins/cache
Anyways after trying a lot of things to attempt regaining control over the value of the AEM credentials set in my pom.xml I figured out how to control the values of the pom.xml environment variables which solved my problems. The way I did that was to install the EnvInject Plugin after which I was able to configure my maven environment variables individually on all my jobs. Everything works great now.
I'd like my XCode Archive builds to automatically tag my SCM (Git in this project).
I've noticed that in the Schema Editor, Archive builds can run pre and post step build scripts. It would be ideal if post steps are only run if the build is successful, and then the tag could go there.
I'd like the tag name to refer to the name of the build configuration (I have TestFlight and AppStore configurations, as well as Debug and Release, which would not normally be archived), as well as the version number that was built, and also the build number. A tag might go something like: TestFlight_2.1.3_#11 or AppStore_2.9.0_#3.
In XCode's project settings, you can use variable substitutions, such as $(BUILD_CONFIGURATION). Can these be used in an Archive build script?
I'm also not sure if there is a variable for the current version string and build number of the App. I've not managed to find one if there is.
In XCode's project settings, you can use variable substitutions, such as $(BUILD_CONFIGURATION). Can these be used in an Archive build script?
Yes. Build settings are available as environment variables to scripts that run as part of a Run Script Build Phase. An easy way to see what variables are set (if you don't trust the build log output) is to just put env in a script to print them out, or env > environment.txt if you want to save them to a file.
I'm also not sure if there is a variable for the current version string and build number of the App. I've not managed to find one if there is.
There is not. However, if you want to retrieve the current version you can get it from the project's Info.plist file (and there should be an environment variable pointing to the file for the active project).
Xcode Archive doesn't have a concept of a current build number. Usually you use a script to figure out the build number from some other source (Xcode Server, a counter on your disk, whatever) and then set the CFBundleVersion key in Info.plist to that number.
I found this:
https://github.com/bejo/XcodeIconTagger
Obviously this is not exactly what you asked, as this will tag the icon, but you could probably use it to point you to the right direction.
I have found a way to change a property in TeamCity:
##teamcity[setParameter name='ddd' value='fff']
But unfortunately this change only occurs for the current build. I want this change to be PERMANENT, but TeamCity only changes this for the current running build.
How do I make a permanent change to a system property in TeamCity?
The only solution using TeamCity 6.5 was to edit the Xml configuration file programmatically using a python script.
A build step calls the python script to change the variable during each build.
Use the REST API which is a feature of TeamCity 7.0
Api details here - http://confluence.jetbrains.com/display/TW/REST+API+Plugin#RESTAPIPlugin-BuildConfigurationAndTemplateSettings
I use this method to get and set properties from powershell during a build.