Currently, I use export JAVA_OPTS ... on the command line, but there seem to be other possibilities, using the build.sbt or an external property file.
I have found several relevant github issues here, here and here but the many options are confusing. Is there a recommended approach?
The approach you take to setting JVM options depends mainly on your use case:
Inject options every time
If you want to be able to specify the options every time you run your service, the two mechanisms are environment variables, and command line parameters. Which you use is mostly a matter of taste or convenience (but command line parameters will override environment variable settings).
Environment variables
You can inject values using the JAVA_OPTS environment variable. This is specified as a sequence of parameters passed directly to the java binary, with each parameter separated by whitespace.
Command line parameters
You can inject values by adding command line parameters in either of two formats:
-Dkey=val
Passes a Java environment property into the java binary.
-J-X
Passes any flag -X to the java binary, stripping the leading -J.
Inject options from a file which can be modified
If you want to end up with a file on the filesystem which can be modified after install time, you will want to use sbt-native-packager's ability to read from a .ini file to initialise a default value for Java options. The details of this can be seen at http://www.scala-sbt.org/sbt-native-packager/archetypes/cheatsheet.html#file-application-ini-or-etc-default
Following the instructions, and depending on the archetype you are using, you will end up with a file at either /etc/default, application.ini, or another custom name, which will be read by the startup script to add settings.
Each line of this file are treated as if they were extra startup parameters, so the same rules as mentioned earlier are still enforced; e.g. -X flags need to be written as if they were -J-X.
Inject options & code which never need to be changed
You can hardcode changes directly into the shell script which is run to start your binary, by using the SBT setting bashScriptExtraDefines, and following the details at http://www.scala-sbt.org/sbt-native-packager/archetypes/cheatsheet.html#extra-defines
This is the most flexible option in terms of what is possible (you can write any valid bash code, and this is added to the start script). But it is also less flexible in that it is not modifiable afterwards; any optional calculations have to be described in terms of the bash scripting language.
Related
I'm trying to write a file in my GitHub repo with GitHub Actions. When reading the docs, I stumbled across this:
Actions can communicate with the runner machine to set environment
variables, output values used by other actions, add debug messages to
the output logs, and other tasks.
Most workflow commands use the echo command in a specific format,
while others are invoked by writing to a file. For more information,
see "Environment files".
echo "::workflow-command parameter1={data},parameter2={data}::{command value}"
I don't know Ansible so I don't understand if this is YAML syntax or Ansible syntax.
I've tried to search Google and Stack Overflow but no results for double colon or ::
Can someone give me the link to the appropriate doc for :: or explain what this command does?
in other words, what does the example in my post throws in the shell? where are data and parameter1 and parameter2 defined if they are (in the yml, in the shell/env)? is command value a value i can reuse in the yml or in the shell?
The ::command can be logged to the console by any script or executable. They are special strings the GitHub runner will detect, interpret and then take the appropriate action on.
They are essentially the communication mechanism between the runner and the thing it's currently running. Anything that can write to the console can issue these strings.
It's totally up to you to build these stings, to inject any parameters these 'magic strings' require to function.
The docs you've found are the right docs on these to understand how to log there strings and what commands there are available to you.
If you're building a GitHub action using the JavaScript/Typescript toolkit, then it provides nice wrapper functions for these commands. The JavaScript SDK also gives you a sneak peak into how to composekthese strings.
If you're building a composite action, container task or are directly issueing commands from a script block in the workflow, then it's up to you to build the correct strings and log these to the console.
More details:
https://github.com/actions/toolkit/blob/main/packages/core/README.md
https://docs.github.com/en/actions/using-workflows/workflow-commands-for-github-actions (you had found that already)
Communicating through the console is the lowest common denominator between any tools running on just about any platform and requires no interprocess communication if any kind. It's the simplest way to communicate from a child process to it's parent.
You'd use the command to set an output variable.
echo "::set-output name=name::value"
To be able to reference the value cross at you'd reference any output variable from any action.
Or set an environment variable which will be set for the next job: echo "action_state=yellow" >> $GITHUB_ENV
See: https://stackoverflow.com/a/57989070/736079
So I got this error when added additional parameters. Now I've got 14 parameters, when I had 11 it worked fine. Is there any way to increase number of parameters powershell can send to jmeter ?
The number of arguments doesn't really matter, you might be suffering from CreateProcess API function parameter length limit which is 32767 characters.
Also it might be the case there is a problem with your filesystem, follow How To Fix File System Error -1073741819 in Windows 10 article for troubleshooting steps.
Also be aware that if you're passing multiple JMeter Properties via -J command-line arguments you can avoid this by putting the properties values into user.properties file or create your own .properties file and pass it to JMeter via -q command-line argument.
References:
Full list of command-line options
Apache JMeter Properties Customization Guide
Overriding Properties Via The Command Line
I am not sure this is clear to me and if is neat for my system. I'm aware of the ~/.zhrc file where I can store alias and paths, but today after installing node via brew I was asked to put this: export PATH="$HOME/.npm-packages/bin:$PATH" in my ~/.bash_profile file, which it doesn't exist, thus in my effort to keep my system clean I putted it in the former file but emacs complaint. Now, I removed it and putted it, after creating, in the ~/.bash_profile. Is that OK to keep both in the home directory?
You need to provide the exact wording of whatever error or warning message you
get from emacs to ensure accurate or better answers. However, I will make a
guess and assume the warning you are getting is from the exec-path package.
This package has a check, which you can disable, that looks to make sure you
have variables defined in the correct init file.
In general, most shells support two types of configuration files
Startup or Login init files
Interactive shell init files
The difference is how often or when the files are sourced (loaded). To
understand the difference, you really need to understand when a shell is run and
the relationship between each shell. I'll try to give a vary high level
explanation, but you really should read the manual page for the particular shell
you are using.
Think of your environment as a tree of shell processes. When you login to the
system, a login shell is created. This shell will be the parent of all the other
shells you create. Each time you run a command, it is executed in a new shell
(this isn't 100% accurate, but is accurate enough to explain the main
points). So when you open a terminal, it runs another shell which is a child of
your login shell. When you execute various commands, the system creates a new
shell and runs that command inside the shell. These are all children of your
parent login shell. Some shells only exist for a short period of time (as long
as it takes to execute the command), others may last for hours, days or possibly
weeks (such as the shell that emacs is running in).
The important point to keep in mind is that child shells inherit various
settings from the parent shell. The idea of the 'export' command you will see in
front of some variables is actually a command to the shell telling it to export
the variable to child shells. For example, if we have a line like
export PATH=/usr/local/bin:/usr/bin:/bin
what we are really doing is
PATH=/usr/local/bin:/usr/bin:/bin # set the variable
export PATH # make it available in child shells
We don't always want variables to be exported as some variables need to be reset
in the child shell itself. For example, the variable holding the prompt string.
It would not work to have this variable only defined in the login parent shell
if you want the prompt to have dynamic components, such as the current
directory, date or time. We want these types of variables to be defined in each
shell when it is created.
To handle this, shells have the two different init files. The login init files
are only sourced for the parent shell and are particularly useful for setting
variables that will be common to all child shells. the per-shell init files are
sourced for every new shell and are best used for setting things which need to
be updated or changed each time a shell is started. There are also other shell
configuration files which can be used for other special purposes, such as when
you log out or log off a system, or to just put alias definitions in etc.
Once upon a time, it made a big difference where you put your variables as there
was a performance hit when sourcing these init files. If the per-shell init file
was too large and consumed too many resources, the whole performance of your
environment could be affected. This is largely less of an issue these days due
to increased processing speeds. Unfortunately, because many people didn't
understand the role and relationships between the different shell configuration
files, there is lots of incorrect or misleading information out there regarding
where values should be set. People often advise setting variables in (for
example) bashrc when they should be set in the bash__profile=. The confusion is
partly caused by the fact you can add a variable to bashrc and it will work when
you test it (usually because your test involves forking a new child shell) and
putting it in your bash_profile will only work after the next login.
There are also some platform differences which make things a little less
clear. For example, under OSX, there is actually a special file in the /etc
directory where you should add additional path components (I'm not on a mac just
now, but it is something like /etc/paths or a per path component file in
/etc/path.d). This is done so that you have a global place to set paths which
will ensure desktop processes, such as the dock, which do not run as a child
process of your login shell, are able to be set.
As a general rule, most variables can go in the login profile, with the
exception of variables relating to the prompt or other variables which have a
dynamic content i.e. content which changes depending on time, directory
location or other tracking of interactive actions which are specific to a shell
instance.
Setting of the path (noting OS differences as described above) should go into
the profile or login configuration file. Under bash, this is .bash_profile and
under zsh, it is typically .zprofile. As bash has become the most common shell,
documentation etc often advises adding things to .bash_profile. If your running
zsh, then add the same information using .zprofile.
As you have said you don't have a.bash_profile, but you do have a zshrc file, I
am assuming you are running zsh rather than bash as your login shell. This being
the case, you need to add that path setting to .zprofile in your home
directory. The exec-path package is complaining because you added it to
zshrc/bashrc, which are not the correct place to set path variables. If your
running under OSX, you really need to add the path to the correct file in /etc
(you will need to check the OSX documentation as I cannot remember the precise
filename).
I'd like to be able to modify some build tasks in response to command line parameters. How do I (can I?) access command line parameters from the Build.scala file?
I don't think it's possible and you should rather resort to using input tasks or environment properties with -D.
I'm trying to set up a new build configuration in TeamCity using the Powershell runner. However, I can't seem to find a way to access the TeamCity System Properties in the build script. I've seen hints that it is possible, but cannot find documentation on how to do it.
I have tried accessing the system properties using Powershell variable syntax, $variable. I have also printed out all variables in memory and see no teamcity variables to use.
Is this possible with the Powershell runner, and if so what is the syntax necessary to get it working?
TeamCity will set up environment variables, such as build.number (you can see a list of these within TeamCity).
In Powershell you can access environment variables using the env "provider", e.g.
$env:PATH
TeamCity variables are accessible by replacing the . with a _, so the build.number variable can be accessed as
$env:build_number
As it says in the TeamCity documentation, the system parameters are passed to the build script runner, but not all build script runners know what to do with them. In the case of the Powershell script runner, when using a script file, they don't propagate down to your scripts.
It's occurred to me to write a psake-optimized build runner that does, but in the meantime you can do one of the following:
explicitly map any of the TeamCity build properties to script parameters using the parameter expansion that's available within the Script Source box. eg .\build.ps1 -someParam:%build.name%
use environment parameters, which can be accessed explicitly within PowerShell using $env:NAME_IN_TEAMCITY syntax, eg $env:TEAMCITY_VERSION, or looped over and pushed into variable scope
access the build properties file that TeamCity makes available during the build. The file is available at $env:TEAMCITY_BUILD_PROPERTIES_FILE, and if you load the XML version it's fairly easy to loop through and push them all into scope (though you do get everything as a string of course). I posted a gist on how to do this (https://gist.github.com/piers7/6432985). Or, if using Psake, modify the script above to return you a hashtable which you can pass directly to Psake's -properties argument.
It is posible. Here is example how to pass system properties into PSake script:
& .\psake.ps1 -parameters #{build_number=%build.number%; personal_build=%build.is.personal%}
If you don't use Psake, you can define your variables like this:
$build_number = %build.number%
The %build.number% part will be replaced with TeamCity provided data. I think, it works only in Source code script input mode.
I created a meta-runner that will pass through System parameters to parameters declared in the Powershell script. It's not perfect (if you put '# in your source it will break) but it works for what I needed, you can find it here: https://gist.github.com/anonymous/ef60ada3f48f0fb25093