Id like to set different value for environment variable in circle.yml depending on branch name.Is it possible?
What i have:
machine:
environment:
MYVAR:"VAL1"
What id like to have is to be able detect type of the branch (master or not) and assign respective value to the variable?
See: Build Details
CIRCLE_BRANCH
The name of the Git branch being tested, e.g. ‘master’, if the build is running for a branch.
so, you can use CIRCLE_BRANCH ENV for detect current branch. After, you can add some logic in code for use MYVAR_xxx or MYVAR_yyy according to CIRCLE_BRANCH.
No, this is not possible using CircleCI due to how shells and environment variables work in our system.
-Ricardo
Developer Evangelist, CircleCI
Related
I know about organization-wide secrets for GitHub Actions, but I'm looking for a way to define organization-wide non-secret variables, such as default environment variables or something similar.
Sometimes you simply don't want all your shared config to be secret. An example is for AWS credentials, where it may be beneficial to see the AWS_ACCESS_KEY_ID in plain text, but keep the AWS_SECRET_ACCESS_KEY as a secret.
It seems silly to have to put the same AWS_ACCESS_KEY_ID variable as an env variable in every single repo, while the secret half of that pair works perfectly to configure once for the entire organization... Is there such a way?
Perhaps a workaround could be to create a reused workflow action such as set-env that sets the shared environment variables and then include that in each and every job such as uses: my-org/github-actions/.github/workflows/set-env.yml#main, but it's not the cleanest solution I think.
Too bad there's simply not an option next to GitHub action secrets to allow them to be ... well, not so secret.
Is it possible to have environment variables on organization level for GitHub Actions? So something like organization secrets but just with environment variables.
Since we have a lot of repositories in our organization I would like to keep the runner version in a global environment variable and so when we decide to update the runner version we can simply change it in the environment settings instead of every workflow file.
EDIT
Variables are now supported on organization level. Here the docs
https://docs.github.com/en/actions/learn-github-actions/variables
You can put the value into the GitHub organization secret. Check the following link to get further details:
https://docs.github.com/en/codespaces/managing-codespaces-for-your-organization/managing-encrypted-secrets-for-your-repository-and-organization-for-codespaces#adding-secrets-for-an-organization
I plan to use the Azkaban https://azkaban.github.io/ for running batch jobs. According to CI ideas we have few environments like dev, test, stage, production and of course job should have different configuration for each environment.
According to Azkaban documentation http://azkaban.github.io/azkaban/docs/latest/#job-configuration Azkaban allows for replacing of parameters whenever a ${parameter} is found. And solution looks like:
system.properties
myFlow/
dev.properties
....
prod.properties
foo.job
#system.properties
env=dev
#dev.properties
dev.database=localhost:2181
#prod.properties
prod.database=aws:port
#foo.job
some command --db ${${env}.database}
And later on each environment we can override the env variable. From my point of view this solution looks strange. Can I just say to Azkaban which property file should be used on environment?
What is the best approach to do it?
An other approach can be found here https://github.com/azkaban/azkaban/issues/1545#issuecomment-339750417
I want to reexecute some targets when the configuration changes.
Consider this example:
I have a configuration variable (that is either read from environment variables or a config.local file):
CONF:=...
Based on this variable CONF, I assemble a header file conf.hpp like this:
conf.hpp:
buildConfHeader $(CONF)
Now, of course, I want to rebuild this header if the configuration variable changes, because otherwise the header would not reflect the new configuration. But how can I track this with make? The configuration variable is not tied to a file, as it may be read from environment variables.
Is there any way to achieve this?
I have figured it out. Hopefully this will help anyone having the same problem:
I build a file name from the configuration itself, so if we have
CONF:=a b c d e
then I create a configuration identifier by replacing the spaces with underscores, i.e.,
null:=
space:= $(null) #
CONFID:= $(subst $(space),_,$(strip $(CONF))).conf
which will result in CONFID=a_b_c_d_e.conf
Now, I use this $(CONFID) as dependency for the conf.hpp target. In addition, I add a rule for $(CONFID) to delete old .conf files and create a new one:
$(CONFID):
rm -f *.conf #remove old .conf files, -f so no error when no .conf files are found
touch $(CONFID) #create a new file with the right name
conf.hpp: $(CONFID)
buildConfHeader $(CONF)
Now everything works fine. The file with name $(CONFID) tracks the configuration used to build the current conf.hpp. If the configuration changes, then $(CONFID) will point to a non-existant .conf file. Thus, the first rule will be executed, the old conf will be deleted and a new one will be created. The header will be updated. Exactly what I want :)
There is no way for make to know what to rebuild if the configuration changed via a macro or environment variable.
You can, however, use a target that simply updates the timestamp of conf.hpp, which will force it to always be rebuilt:
conf.hpp: confupdate
buildConfHeader $(CONF)
confupdate:
#touch conf.hpp
However, as I said, conf.hpp will always be built, meaning any targets that depend upon it will need rebuilt as well. A much more friendly solution is to generate the makefile itself. CMake or the GNU Autotools are good for this, except you sacrifice a lot of control over the makefile. You could also use a build script that creates the makefile, but I'd advise against this since there exist tools that will allow you to build one much more easily.
I am trying to do "continuous integration" with TeamCity. I would like to label my builds in a incremental way and the GUID provided by the VCS is not as usefull as a simple increasing number. I would like the number to actually match the revision in number in Mercurial.
My state of affairs:
Mercurial info:
I would like the build to be labeled 0.0.12 rather than the GUID.
Would someone be so kind and save me hours of trying to figure this out ?
As Lasse V. Karlsen mentioned those numerical revision numbers are local-clone specific and can be different for each clone. They're really not suitable for versioning -- you could reclone the same repo and get different revision numbers.
At the very least include the node id also creating something like 0.0.12-6ec760554f2b then you still get sortable release artifacts but are still firmly identifying your release.
If you're using numeric tags to tag releases there's a particularly nice option:
% hg log -r tip --template '{latesttag}.{latesttagdistance}'
which, if the most recent tag on that clone was called 1.0.1 and was 84 commits ago gives a value like:
1.0.1.84
Since you can have different heads that are 84 commits away from a tag in different repos you should still probably include the node id like:
% hg log -r tip --template '{latesttag}.{latesttagdistance}-{node|short}'
giving:
1.0.1.84-ec760554f2b
which makes a great version string.
The best and easiest way to see rev. number in TeamCity build number is to use Build Script Interaction with TeamCity. Namely, it has a possibility to set Build Number.
So, add to your project a new very first build step Command Line with following Command Executable
for /f %%i in ('c:\tortoisehg\hg id -n') do echo ##teamcity[buildNumber '%%i']
And you will get the Mercurial revision number as a label for your every build.
Of course you can change the command in quotes to anything you wish.
I believe my answer is way more correct than the accepted one.
EDIT:
Also you can do the same via MSBuild task rather than Command Executable. Have a MSBuild project file with following code, setup TeamCity to run it as first step, and it will alter its global variable buildNumber:
<Message Text="##teamcity[buildNumber '$(CurrentVersion)']" Importance="High" />
Where CurrentVersion is a string containing full version (for example "1.0.56.20931").
hg id produces the hash (6ec760554f2b), hg id -n produces the local revision number (12).
(Note this is an answer purely from the hg side, how you then get that into TeamCity, I don't know, as I've never used it.)
I managed to use it in Teamcity using a workaround:
<Exec Command="hg log -r tip --template {latesttag}.{latesttagdistance} > $(BuildAgentTempDir)\version.txt"/>
<ReadLinesFromFile File="$(BuildAgentTempDir)\version.txt">
<Output TaskParameter="Lines" ItemName="versionInfo"/>
</ReadLinesFromFile>
<TeamCitySetBuildNumber BuildNumber="#(versionInfo)-{build.number}" />
If you see the MSBuild task "TeamCitySetBuildNumber" I'm using the "{build.number}" variable because it substitutes this with what you set in the build number originally. I used %build.vcs.number% in my original settings (in the Web UI) and the result is just what Ry4an wrote above!
Hope it works for you!
When I used to use Subversion I used to do something similar in TeamCity. The format was:
{Major}.{Minor}.{TeamCity Build No.}.{Subversion Revision No.}
This allowed me to look at an assembly and see which build it came from on TeamCity and the revision number from subversion.
I have now moved to Git which has put me in the same situation as you. After playing with various ideas I have come to the conclusion that I don't actually need the revision, the build is good enough. Because TeamCity is such a powerful tool, all you need is the build number, given the build number you can look at the build history and determine the revision from that.
{Major}.{Minor}.{Macro}.{TeamCity Build No.}
Additionally you can get TeamCity to label your repository with the build number allowing you to look up a given build in your source control.
When providing your build number with numeral mercurial revision, you must be aware, that those numbers are clone-specific and can differ from clone to clone.
In our project we had the same issue. We're using TeamCity 7.1.1. We solved it in the following way:
Add Command line build step to your configuration.
Make this build step run first.
In the build step properties select "Run: 'Executable with parameters'"
Add the following text to Command Executable:
for /f %%i in ('hg id -n') do echo ##teamcity[buildNumber '%%i']
Save changes.
You can also use previously generated build number when performing step 3.
Example:
for /f %%i in ('hg id -n') do echo ##teamcity[buildNumber '%system.build.number%.%%i']
You can use this to make build counter present in your build number.
Read this to get more information!
Remember that teamcity compiles configurations build number before build starts and the correct build number will appear only after your build step will finish its job. That's why, in some cases (f.e. inserting your mercurial revision into artifact's name) you should define build number's value in preceding configuration and refer to it.
Example:
%dep.bt82.build.number%
Read this to get more information!