I'm trying to figure out how to make the build work in TeamCity. One of the problems is that I cannot get the correct version. In General settings tab, I have a build counter which works well (it increments every time I run a build). However:
If I don't define build.vcs.number in Parameters, TeamCity shows it anyway, marking that the value is required, and the parameter is undeletable.
If I define build.vcs.number and set the value to an empty string, I end up with the version 1.0.0.. If I set it to any value, such as 123, the version would be 1.0.0.123.
If I define build.vcs.number to be %build.vcs.number%, like in the third screenshot in a similar question, it seems that the parameter just references itself, and TeamCity doesn't know what to do in this case, and I get 1.0.0.???.
So how do I point build.vcs.number to the counter I see in General settings?
build.vcs.number is specific to your VCS. The build counter is build.counter. You shouldn't have to define them as build parameters. What are you trying to use the value for?
Related
Trying to use BackendListener and observed runtime variables are not written to influxDB.
Predefined variables and properties, on the other hand, can be written to influx.
So I can separate test results by some ID by setting measurement=${__P(SOME_ID)}
What I'm looking for is a splitting results by thread group name, as I may have up to several dozens of them within the same test.
Tried to use following:
TAG_scenarioName=${__threadGroupName}
TAG_someJmeterVar=${SOME_JMETER_VAR}
TAG_someJmeterVarAsGroovy=${__groovy(vars.get("SOME_JMETER_VAR"),)}
eventTags=${__threadGroupName} testTitle=${__threadGroupName} (this
one makes less sense, but still..)
and none of those works
Those are works:
- TAG_injectorName=${__machineName()}
- TAG_predefinedVar=${USER_DEFINED_VAR} (I believe this is thanks to this)
So as I understand problem is with runtime variables only. Is it possible to make runtime variables accessible for the BackendListener? Or maybe there is some workaround for such case?
p.s. opened an enh for this
Based on your inputs. Please try with "sample variables"
These are defined in user.properties like:-
sample_variables=FileName,retHREF,PageID,Redirect,StatusCode
So, put all your variables in the sample_variables, restart jmeter and try. Please check if this helps.
This is not possible as of JMeter 5.1.1 (last version at time of this answer).
It's a feature request which is not implemented yet:
https://bz.apache.org/bugzilla/show_bug.cgi?id=57962
I am experimenting with a blue/green deployment setup for lambdas using terraform and lambda aliases.
I am trying to automatically retrieve the previously deployed version of the lambda by using the aws_lambda_function data source and using the value inside the routing_config => additional_version_weights. This would allow me to set up a traffic split between the previously deployed version and the version that has just been deployed.
However, I have run into 2 errors I don't quite understand.
The first error is when I try and use the data source in conjunction with a regular variable. In this case terraform complains about being unable to parse the value.
If I hard code the value terraform will attempt to run the update, however, it will fail as it tries to set the version in the routing configuration to an empty value which causes a validation error. If I instead output the value I can see that the correct version is retrieved.
Example code and steps to reproduce can be found on link below.
https://github.com/jaknor/terraform-lambda-data-source-issue
Is anyone able to explain why this isn't working?
Please note, while I appreciate that there are other ways of achieving my goal, at the moment I am only interested in understanding these particular errors.
In Terraform v0.11 and prior, interpolation sequences are not supported on the left side of an = symbol introducing an argument or object key.
To generate a map with dynamic keys, you must instead use the map function:
additional_version_weights = "${map(data.aws_lambda_function.existing_lambda_func.version, var.lambda_previous_version_percentage)}"
In Terraform v0.12 (which is in beta as I write this) the parser is now able to distinguish between arguments (which must be constants in the configuration) and map keys (which can be arbitrary expressions) and so the following syntax is preferable, although the above will still work for backward compatibility.
additional_version_weights = {
(data.aws_lambda_function.existing_lambda_func.version) = var.lambda_previous_version_percentage
}
The additional parentheses around the key expression are important to tell Terraform that this should be understood as a normal expression rather than as a literal name.
Our generic Maven build needs to pass on a number of properties to child processes.
Right now, we are providing these as environment variables, and reading them in individually as properties.
These properties are then substituted into a file to configure a test runtime, and provided to the Failsafe plugin as environment variables for the test run.
The above is fine, except for a couple of things:
The environment variable -> property map is manual - we need a property definition for every environment variable we want to pull in.
Specifying environment variables to Failsafe is again manual - we need a variable definition for every environment variable we want to pass on.
Right now, if we have 20 environment variables, we have 20 lines for each of these stages, and that's getting tedious quickly.
Is there a better way to do this?
My naive thoughts include (though I can't find a way to achieve it):
Define Maven properties dynamically, potentially based on a regex, from environment variables.
From Maven properties, automatically construct a list of environment variables, to be passed to Failsafe, again preferably via a regex.
With one of the recent Xcode updates it keeps telling my to try and use "let" rather than "var". Why? I would have thought "var" would be the best to use and to only use "let" in specific situations.
It is the opposite that is true, let is safer.
With let the developer is explicitly stating that the value is a constant that should not change and the compiler insures this, it enforces the developers concept of the usage.
With var the developer is explicitly stating that the value can change, that change is expected. In the case that the value is not changed the compiler is notifying the developer of this and that the developer can (should) change to let.
By the compiler enforcing this the code base is safer from inadvertent value changes.
You should always try to do the safest thing possible. If you can modify an object then you can modify it by mistake. If you can't modify an object then you can't modify it by mistake. Therefore if you don't want to modify an object or value you should use "let" and not "var".
Or look at it the other way round: If you use "var" you declare you intend to modify the value. If you don't modify the value, it may be because you used the wrong variable name. Say you have var x and var y, then you write x = 100 and x = 200. You used the wrong identifier in the second case. The compiler detects that your intent and actions were different.
I have an issue in which I need some code to run as a result of a command builder:
node = env.Command (target, dependencies, function)
In this case, function will run if the target is out of date, which is what I want, but if the target is in the cache, function doesn't run. What I'd like is to run a different function if the target is pulled from cache.
I tried:
env.AddPostAction(node, function2)
but that function doesn't get called either.
Any ideas? Thanks.
Afaik, scons will not know how it will satisfy the demand while executing your code. It makes that decision after completing the 1st pass. So, even if you could tell, I don't believe you could act on it within your code.
An easy, obvious way is to parse the scons output for 'Retrieved ... File name'.
And of course, the problem suggests the dependencies are set up badly, and it looks like you fixed that.