I was wondering why the property quarkus.http.auth.form.timeout has to be defined at build time. I would like to change it's value on different installations, and having to rebuild the whole application just for that makes things much more complicated.
Marco.
Since it's an application.property, have you tried to set the value by an environment variable? eg.
quarkus.http.auth.form.timeout=${AUTH_FORM_TIMEOUT}
This way you could dynamically change it with each deployment with setting AUTH_FORM_TIMEOUT to different values.
Related
Context:
We build our maven apps in which version number is injected by a build.properties file. Problem with this approach is that for every release, version number needs to be bumped manually.
Browsing online to fix this problem, i bumped into version number plugin which offers some cool ways to fix the issue.
For instance -Dproject.version=${BUILD_YEAR}.${BUILDS_THIS_YEAR} will solve the issue for me
Problem
I have issue setting up the values for the defined variables
Quoting from the doc:
Initialization Values
Before the build is started, the number of
builds this year / month / week / day can be specified on the command
line or via the job's plugin-configuration web-GUI. If they are
specified, then they will override whatever values are currently in
production. This allows you to migrate your version number from
another system to Jenkins if you choose to do so.
Additionally, it is possible to automatically override the number of
builds this year / month / week / day with values taken from
environment-variables. Instead of just providing a simple number in
the form-fields of the job's plugin-configuration which overrides the
value for the next build (as described above), you can instead provide
an environment-variable whose value will be extracted and used during
the next builds. If it is not set or its value is not convertible to a
positive integer (without loosing precision), the value of the
previous build will be taken instead and increased by one (as is the
standard behavior).
In the last sentence, it says
If it is not set or its value is not convertible to a positive integer (without
loosing precision), the value of the previous build will be taken instead
and increased by one (as is the standard behavior)
So, going by this i built an jar with injected values of BUILD_YEAR and BUILDS_THIS_YEAR, worked as expected (jenkin says Building my_app_2019.1-SNAPSHOT). After that, i removed the variables assuming that they would be picked but unfortunatley jenkin says Building my_app_${BUILD_YEAR}.${BUILDS_THIS_YEAR}-SNAPSHOT.
There is no relevant doc around this or may be i have missed something totally obvious
Question
How do i ensure these var are injected correctly in my maven builds? or rather how do i populate the values using the plugin?
This is not a jenkins pipeline, its a simple jar builds.
Missed setting up Create a formatted version number as below :
updated as per image above and changed command to -Dproject.version=${VERSION_NUMBER}-SNAPSHOT.... voila!!!!!
I like to modify my Windows environmental variables by opening the Advanced System Settings -> Environmental Variables. I particularly like that when I try to modify the system path (by clicking on System Variables -> Path), that I get a nice, easy to read list of the folders on the path:
However, when I click on the User Variables -> Path, I still get the old dialog, which is not very user friendly:
Is it possible to have Windows always display the list, as is the case for the System variables?
For what its worth, I think I remember seeing the desired behavior on a friend's computer, so I believe it should be possible.
EDIT:
It seems that having a variable as part of the path is the problem. Is there a way to get path list even when the path contains variables?
Context:
When I want to add a program to my path, I will create a new variable that redirects to its path. The reason to do that is simple... Programs typically have compound paths, and so making a consolidated variable seems like a wise decision. For instance, on my machine, I have multiple python instances (sometimes I need an Anaconda installation of Python 3.6, and sometimes I want a version of the bare-bones Python 3.5). To accomodate this, I create environmental variables for the paths to each installation.
Now if I want to switch which version is on my path, I can simply update my path variable from
path=...;%PATH_PYTHON35%
to
path=...;%PATH_PYTHON36A%
See how easy that was?
The problem is that the GUI doesn't seem to like this for the local variables. I can confirm that this is the case because when I remove the variables from the local path, I get the nice list like the System Variables case. However, what is perplexing to me is that the System Variables path DOES include some variables as well:
So I take this to mean that there must be a way of getting the local variables list to pop up, just like the System Variables case...
Guess I'm late to the party, but this works for me:
PATH=C:\DATA\bin;%JAVA_HOME%\bin
whereas this does not work:
PATH=%JAVA_HOME%\bin;C:\DATA\bin
A speculation based on my own observations.
It seems list view is only presented when at least one of the first two entries begins either with a drive letter notation (like C:\) or a specific variable. I'm not sure which variables are considered "valid", but here are a few environmental variables that show up as list:
%USERPROFILE%+%LOCALAPPDATA%;aaa;bbb;
aaa;Q:\%LOCALAPPDATA%;bbb;
These however show up as a string:
%LOCALAPPDATA%+%USERPROFILE%;aaa;bbb;
aaa;bbb;%USERPROFILE%;
Not sure what makes %USERPROFILE% different, but i tried a few other variables instead of %LOCALAPPDATA% (%OS%, %HOMEDRIVE%) - result was the same.
I am using the latest version of TeamCity and I am trying to make a parameter specification that refers to parameters.
I tried making a select (combobox), where the options of the checkbox are referring to variables. This should be possible, as there is a "parameter" icon to the right of the box suggesting me that I can use parameters here.
The full setup is shown below.
However, when I want to run the build, the only options are literally %foo% and %bar% as if the parameters have not even been evaluated.
Instead I had expected the options to contain the values of the variables that they are pointing to.
What am I doing wrong here?
Might be a bit late, but this is how I did it:
I have a few parameters for holding passwords, e.g. 'mfgpwd'
And I refer to these in another parameter using the syntax:
mfgpwd=%system.mfgpwd%
(I'm using TeamCity 8.1.5)
I have a parameter for which I'm showing a prompt. I've set a default value for it and that works fine.
What doesn't work, however, is that if I choose to enter a different value when running the build, then on the next build this value automatically becomes the new default value, so to say.
I'd like the default value to always be fixed and if you enter a different value in the field, then that value will be used just for this build (and the next build will fallback to the fixed, default value for this parameter).
Is this possible and how can it be done?
Currently it's not possible. The related request is https://youtrack.jetbrains.com/issue/TW-21453, please vote. As of now you can use "Reset" link.
As far as I know, there's no built-in solution for this.
To solve your problem, you could use a Command Line (or Powershell) Build Runner that runs as the last step of the build. There you can reset your parameter by setting it to the desired default value using this as script content:
##teamcity[setParameter name='your.parameter' value='desiredDefaultValue']
I would recommend using a separate parameter to save desiredDefaultValue instead of a hard-coded value.
I am trying to figure out the best way to organize a bunch of Ruby scripts to make it easier on the next person. One key thing is that there are multiple constant variables that need to be used across all scripts. Where should these be stored? Do I keep a separate file for these constants? Should I use YAML? I've never had to create a project with multiple Ruby source files interacting with each other, so I'm not sure as to what the best method of approach is here.
Thanks for the help.
I like to use a config.yaml file for all my constants. This makes it easy to set and change variables that are going to be used across different files. Then all you need to do is read in the file and set the variables. You can keep this file anywhere really, so long as anyone using the file has read permissions. All you have to do then is set the file path.
Hope this helps.
I like to do a config.yml or settings.yml, but I also allow the variables defined in config.yml to be overloadable by ENV variables (might be overkill in your situation).
It's might also be a good idea to set some defaults in your config loading/setting code.
As far as common functions/methods go... common.rb is a pretty good name or maybe shared.rb.