I'm trying to construct a dashboard for git projects. I have an influxDB, which has data for each build in a repo, for every branch.
I have a variable already defined for repository, with the query show tag values with key=repo. What I want is, once that value is set, to have a second variable called branch, that uses the repo variable in it's query. I've tried show tag values with key=branch where repo='$repo', but that doesn't work.
I'm not sure how to make this work.
I figured it out. I needed to surround the variable in slashes:
show tag values with key=branch where repo=/$repo/
Also using InfluxDB. /$variable/ didn't work for me, I needed slightly different escaping. For this particular query I needed =~ instead of = as well.
select "end" from "summary" where "build" =~ /^$build$/
Related
I've been looking around my machine to see where the postman environment variables are stored. I've looked under AppData\Local\Postman, and C:\Users\username\Postman folders, and haven't found a config file that has a last modified date matching my change of environment variables.
I know I can export the environment variables, but I want to search over the current variables. And the exports don't include the current values, unless they replace the initial value, which I want to keep.
There are still ways to get around this. But I want to write a simple command to fetch some current environment variables via cmd, ex using grep.
So is there a way to check for the current environment variables? Where are they stored?
I don't think this will be a successful attempt. Postman seems to use a database, e.g. leveldb, according to information I found here. That will be stored as a binary file on your disk.
You can, however, have a look into the DB by going to View => Developer => Show DevTools and then going to Storage => IndexedDB => variable_sessions => workspace. I can find a current value for an environment variable like this:
But I don't see a way to search in this other than by keys which are uuids and not variable names or values.
All in all, exporting your environments into a text file might be the easiest option.
In build definition (on Variables tab) I am trying to define a custom variable (Build.Repository.Clean) using simple expression $[not(false)]. But when I print variables during build -- regardless of expression used, Build.Repository.Clean value is always false.
Strangely enough, definining it with something like $(FullBuild) (where FullBuild is another custom variable) works just fine.
Am I missing something?
Notes:
using TFS 2018
Backstory:
Trying to set Build.Repository.Clean variable depending on a custom variable QuickBuild (which can be set by user when kicking off a build). Tried specifying $[not(variables.QuickBuild)] (and other variations of same expression) -- no luck.
here is how it works right now (but I'd rather have QuickBuild instead of FullBuild -- just can't figure out how to negate a variable):
Update 3:
Well, ignore if it changes clean operation during queue time. For what you are looking for, you could try this format:
Build.Repository.Clean=$[not(eq(variables.QuickBuild,'True'))]
If QuickBuild=True, Build.Repository.Clean=False,
If QuickBuild=False, then Build.Repository.Clean.Clean=True
For example:
I have set the clean option in Get Source Step, Clean=true
Build.Repository.Clean=$(FullBuild)
FullBuild=false
Now when I queue the build, then try to change the FullBuild=false during queue
time.
What you thought, the Build.Repository.Clean should change to False , then the clean operation will not be executed. But the truth is, the Build.Repository.Clean is still True and the clean is executed.
Even you do not update the value of FullBuild=false during the queue time, directly set the value FullBuild=false in build pipeline. This will also not use.
In the opposite, if you set Clean=false in Get Source Step. No matter what kind of value you input in FullBuild or Build.Repostiory.Clean during queue build.
It will not clean during the build pipeline.
Conclusion: It's not able to change the clean operation during queue time. This is not related any expression at all. Not matter what kind of value you set for Build.Repository.Clean.
Update 2
After go through your question and all comments once again. Seems your truly goal is assigning the clean options at queue-time based another customized variable.
Since you are not able to change Build.Repository.Clean during queue time. So you are trying to use this workaround. It's not support. There is not a way to assign the clean options at queue-time.
You may have to pre-define this variable in your build pipeline.
Also take a look at this question: How to clean build using self-hosted agent when queuing
In your scenario, you can create two build pipelines as an ugly workaround. One for incremental build (Disable the Clean option in get source step, or use variable Build.Repository.Clean = False), and another one enable the Clean option.
Hope it's clearly.
Expressions are not evaluated when they are used to initialize custom variables (on Variables tab). I.e. variable value ends up being a string with value equal to your expression (e.g. '$[not(<whatever>)]'). Later, when that variable gets used in context that expect boolean -- it still doesn't get evaluated, instead it gets type-casted and any non-empty string yields true.
On the other hand variable substitution happens -- i.e. value $(MyVar) gets replaced with value of MyVar.
Built-in variable seem to be special in sense that if you override them -- this process happens at the start and it's value gets immediately replaced with resulting value.
Note -- this may (or may not) be related to this.
Bottomline: you can't use expressions to override value of a built-in variable.
Let's say I have a rule like this.
foo(
name = "helloworld",
myarray = [
":bar",
"//path/to:qux",
],
)
In this case, myarray is static.
However, I want it to be given by cli, like
bazel run //:helloworld --myarray=":bar,//path/to:qux,:baz,:another"
How is this possible?
Thanks
To get exactly what you're asking for, Bazel would need to support LABEL_LIST in Starlark-defined command line flags, which are documented here:
https://docs.bazel.build/versions/2.1.0/skylark/lib/config.html
and here: https://docs.bazel.build/versions/2.1.0/skylark/config.html
Unfortunately that's not implemented at the moment.
If you don't actually need a list of labels (i.e., to create dependencies between targets), then maybe STRING_LIST will work for you.
If you do need a list of labels, and the different possible values are known, then you can use --define, config_setting(), and select():
https://docs.bazel.build/versions/2.1.0/configurable-attributes.html
The question is, what are you really after. Passing variable, array into the bazel build/run isn't really possible, well not as such and not (mostly) without (very likely unwanted) side effects. Aren't you perhaps really just looking into passing arguments directly to what is being run by the run? I.e. pass it to the executable itself, not bazel?
There are few ways you could sneak stuff in (you'd also in most cases need to come up with a syntax to pass data on CLI and unpack the array in a rule), but many come with relatively substantial price.
You can define your array in a bzl file and load it from where the rule uses it. You can then dump the bzl content rewriting your build/run configuration (also making it obvious, traceable) and load the bits from the rule (only affecting the rule loading and using the variable). E.g, BUILD file:
load(":myarray.bzl", "myarray")
foo(
name = "helloworld",
myarray = myarray,
],
)
And you can then call your build:
$ echo 'myarray=[":bar", "//path/to:qux", ":baz", ":another"]' > myarray.bzl
$ bazel run //:helloworld
Which you can of course put in a single wrapper script. If this really needs to be a bazel array, this one is probably the cleanest way to do that.
--workspace_status_command: you can collection information about your environment, add either or both of the resulting files (depending on whether the inputs are meant to invalidate the rule results or not, you could use volatile or stable status files) as a dependency of your rule and process the incoming file in the what is being executed by the rule (at which point one would wonder why not pass it to as its command line arguments directly). If using stable status file, also each other rule depending on it is invalidated by any change.
You can do similar thing by using --action_env. From within the executable/tool/script underpinning the rule, you can directly access defined environmental variable. However, this also means environment of each rule is affected (not just the one you're targeting); and again, why would it parse the information from environment and not accept arguments on the command line.
There is also --define, but you would not really get direct access it's value as much as you could select() a choice out of possible options.
I am trying to create a variable in TFS for my task for timestamp in format yyyymmdd. I know that I create a task specifically for this using bash or powershell. However, I am looking to find some existing variable or some way to create this variable without having to setup a task dedicated for itself.
So far I have tried to use $(Date:yyyymmdd) in my variables but it does not put values in it, it uses variable name as is.
For example, C:\Alpha\beta\$(Date:yyyymmdd) instead of C:\Alpha\beta\20191107
Can anyone help me with this ? Thanks a lot
Actually, it is hence not expanded. We do not have this kind of system or environment variable which get current date time and work every. You may have noticed you could use $(Date), however which is only available in the Build number format section. Others such as $(Rev:r) and $(DateOfYear) are the same, do not work outside the BuildNumberFormat-Settings..
Take a look at the list of all system and environment variables here: Predefined variables
As you have pointed out, you need to use a script in a PowerShell Task to set a variable in your build definition, a sample:
$date=$(Get-Date -Format 'yyyymmdd');
Write-Host "##vso[task.setvariable variable=time]$date"
Then you can use $(time) in your subsequent build tasks.
More details also take a look at this similar question: VSO(TFS) - get current date time as variable
I've got a Jenkins build with a choice box for build prefixes by release. It helps trigger a job based off the value of whatever specific build the person wanted.
I wanted to take the value of that choice box and transform the variable into the correct prefix based off the naming conventions typically used on this server for triggering the job based off its name.
So let's say I've got build prefix choices specifically for,
ReleaseOne
ReleaseTwo
none
For none, meaning the parameters used won't try to access or set any specific release-based info by triggering the non-release-specified build.
I wanted to take the value of Release_Prefix and transform it, if needed, for the job that I trigger later. I was hoping to accomplish this with a dynamic parameter or similar mechanism. I'm not sure if my script is bugged, or something fundamental is not working to my intent. This might be the case, based off some alluded feedback from a similar question.
Can I do something like this snippet below? If not with Dynamic Parameter plugin + GroovyScript, what would you suggest? This currently seems to return nothing, regardless of my choice.
Formatted_Prefix parameter, Dynamic Parameter
switch(binding.getVariables().get("Release_Prefix"))
{
case "none":
return "";
case "ReleaseOne":
return "ReleaseOne_";
case "ReleaseTwo":
return "ReleaseTwo_";
default:
def prefix = binding.getVariables().get("Release_Prefix")
return "$prefix_";
}
There's multiple ways I can overcome this, but if I can do it at the initial parameter stage, that would be best for me.
You can use EnvInject Plugin for this.
check the checkbox Prepare an environment for the run and
write your script inside Evaluated Groovy script text box
def prefix1 = Release_Prefix + "mydata"
return[prefix:prefix1]