Tell me please what's the right way to change e.g. an api url by changing the git branch for requests to the right server.
i have two servers (for example):
https://www.production.com
https://www.development.com
and two branch:
master
dev
is there any way to do like this:
let uploadSomethingUrl = url + "/upload/something"
where url is set depending on the checked out branch
"dev" is checked out -> https://www.development.com/upload/something
"master" is checked out -> https://www.production.com/upload/something
No, you cannot check which branch you currently checked out and react on it in code.
But what you can do is set configuration for Debug and Release Builds (or any other custom you want). It may take some fiddling around if you haven't done this before, but this is a clean way to achieve your goal. Here is a guide on how to do it
using xcconfig for you xcode project
You can access these setting in your code, read here:
How can I access a user-defined Xcode build setting?
Related
I'm constructing some build scripts using FAKE for a TeamCity setup. Part of my build requires me to access the teamcity.build.branch parameter, however because it's not an environment variable, I'm not sure how to access it.
I've tried adding %teamcity.build.branch% to an environment variable in TeamCity but it doesn't seem to like that. I also can't access it using the FAKE git module because team city agents don't use git to get the project files, TeamCity hands it to them.
How would I go about getting the teamcity.build.branch parameter through to my FAKE scripts? Ideally I'd like it as an environment variable so I can pick it up straight from within the script, but I'm open to any other ideas.
Try passing %teamcity.build.branch% as a parameter in your build step.
I figured it out with a bit of help from #Nadeem's answer.
I now have my build.bat/cmd file taking in a parameter which I'm then passing into my Fake.exe call like so:
"packages\FAKE\tools\Fake.exe" build.fsx branch=%1
Then inside my FAKE code I'm using the getBuildParamOrDefault "branch" <default branch here>.
I'm then using this as the branch name. I'm also using a string split on the build param that comes in because normally it's in the format of ref/head/<branch name> and I only want the branch name.
I also had to pass in %teamcity.build.vcs.branch.<project>% instead of %teamcity.build.branch% as my agents didn't like the implicit requirement. I'm not entire sure why this is but all is working well now.
We are using Octopus Deploy and we would like to have two feeds, one for development branch and the other for our main branch in TFS. When we are done with a piece of functionality we merge it from the development branch to the main branch. We have builds for both branches that produce nuget packages. The DEV builds get the code from the DEV branch and publish nuget packages to the DEV feed, the MAIN builds get from the MAIN branch and publish packages to the MAIN feed. We'd like the dev build to automatically kick off a deployment in Octopus and have it use the nuget packages from the DEV feed. We'd also like to use that same Octopus deployment project to deploy to our QA, Production, and Training environments but from the MAIN feed instead of the DEV feed.
We have tried a couple different ways to solve this problem but haven't been successful yet. The Octopus UI for creating the steps allows a variable entry in the feed field so I'm assuming we can do it but we just have something slightly wrong. But it is possible that, because we have the variable set up based on environment (Octopus environment) that is part of the problem?
We also tried having the TFS build tell Octopus which feed to use and this seems to work to get the release created but when it tries to deploy it can't figure out what that variable is anymore.
I have found these posts with similar or the same problem but no posted solution yet:
http://help.octopusdeploy.com/discussions/problems/16452-custom-binding-of-nuget-feed
http://help.octopusdeploy.com/discussions/questions/2189-separate-nuget-feeds-for-regional-deployments
I have tried creating a variable scoped by environment called testFeed and used the below syntax as the feed value in the step and it allows me to save the change and create a release but when I try to deploy is says "There was a problem with your request. Pre-deployment validation failed: one or more feeds referenced by steps in this project no longer exist. You will need to create a new release.":
#{#{testFeed}|feeds-33}
Fortunately this now has a very easy solution that has been documented by Paul in the comments of this post.
Instead of using the or syntax I had been trying all you have to do is set up an additional variable that is not scoped to environment that acts as the default.
So for my situation, I set up a variable called nugetFeed with the value of feeds-33 (my dev feed) and row in the variable table also called nugetFeed with the value of feeds-34 (my MAIN feed) and scoped it for the QA and PROD environments. Then in the process step feed field use a custom expression of #{nugetFeed}.
Note: once you save the process step it will look like you've choosen the default feed but that is just the UI resolving the value. When you actually deploy it is using the variable values.
Currently there is a bug to watch out for described as: When you enter the #{Feed} variable and save everything works fine. But when you open the package in Edit again the #{Feed} variable is evaluated in the designer to the first of the feeds e.g. feeds-1. If you change something else and save again you process is broken since the feed now has the value feeds-1 and not #{Feed}.
I make builds in Jenkins many times a day and I would like to automate it a little bit, but still access it through web interface.
I'm already selecting job with URL (and building this URL with very simple Alfred workflow) but I would like to also select a branch – we have many branches in repo and 90% of time I want to select master of develop
jenkins.skypicker.com:8080/job/beta/build works great for selecting job, but is there a way to select branch, something like jenkins.skypicker.com:8080/job/beta/build?branch=origin/master?
You can, theoretically, use the Parameterized Build feature to define a parameter later to be used with GIT plugin configuration. Then you should be able to use the format of url like this:
http://jenkins.skypicker.com:8080/job/beta/buildWithParameters?BRANCH=origin%2Fmaster
Be careful with the special character in the branch name though. If you can avoid it by specifying a branch name in the form of origin/$BRANCH it would be safer...
Remember that in order to start the build process one must use POST method, not GET - just a side note...
Anser by #Łukasz-rżanek is right, just adding a few notes on which I've stumbled
Set this in Job configuration:
and run it
#!/bin/bash
JOB_NAME="Beta"
JOB_BRANCH=""
JOB_TOKEN="TOKEN"
JENKINS_URL="http://jenkins..."
crumb=`curl "$JENKINS_URL/crumbIssuer/api/xml?xpath=concat(//crumbRequestField,\":\",//crumb)"`
curl -H $crumb -X POST $JENKINS_URL/job/$JOB_NAME/buildWithParameters?token=$JOB_TOKEN
I'm building a group of projects from the SVN. There is a possibility of changing the SVN location time to time. As there are bunch of projects I hope to give the repository url with a environment variable so i can change all the url's easily. Any idea how to do that??
In Subversion Source Code Management, you can use variable in the Repository URL, simply type:
http://my.svn.com/path/to/${VARIABLE}
${VARIABLE} is a job parameters that is defined earlier. Never heard of anyone wanting to use actual environment variables for this, but you can try with the same syntax.
By default, it will give you a red warning that this is not a valid URL. You can disable this warning by going to Manage Jenkins -> Configure System and look for Validate repository URLs up to the first variable name. Put a checkmark there and save.
i want to add repository svn like this https://.../svn/IOS/xxxx
but the xcode always change it to this: https://.../svn/IOS
It sounds like XCode is saying that it wants you to enter the URL to the root of your repository. It then provides a UI that will let you browse and select the path within the repository that you want to checkout. This might just be for UI reasons so that, for example, if you want to access /branches or /tags later you can do so via the same UI.