I exported a variable called DBURL='postgresql://string'and I want to use it in my configuration ini file, e.g::
[app:kotti]
sqlalchemy.url = %(DBURL)s
That's not working.
Put this in your __init__.py:
def expandvars_dict(settings):
"""Expands all environment variables in a settings dictionary."""
return dict((key, os.path.expandvars(value)) for
key, value in settings.items())
Then when you export an environment variable to your shell, the proper syntax is this:
sqlalchemy.url = ${DBURL}
Once you have that environment variable set within your .ini, then you can use the configparser syntax:
sqlalchemy.connection = %(sqlalchemy.url)s%(user:pass and other stuff)s
Idea stolen from https://stackoverflow.com/a/16446566/2214933
PasteDeploy (the ini format pyramid is using here) does not support reading directly from environment variables. A couple common options are:
1) Set that option yourself in your main.
import os
def main(global_config, **settings):
settings['sqlalchemy.url'] = os.environ['DBURL']
config = Configurator(settings=settings)
...
2) Define your ini file as a jinja2 template and have a command to render it out to ini format, and just run that as part of your deploy process.
In previous versions of TFS (before 2015), there was a build environment variable for PowerShell called: TF_BUILD_DROPLOCATION, which gave the The location of the drop:
https://msdn.microsoft.com/library/hh850448%28v=vs.120%29.aspx.
I can't find the equivalent variable in TFS 2017.
What is the best practice to get it?
With Build agent tasks taking over things are different. What I do to see the various build environment variables is to make a simple batch file containing this:
SET C:\temp\EnvVars.txt
That'll produce a quick list of what is available.
Here's what I see with the TFS 2017 build agent:
agent.jobstatus=Succeeded
AGENT_BUILDDIRECTORY=C:\Agent\_work\2
AGENT_HOMEDIRECTORY=C:\Agent
AGENT_ID=2 AGENT_JOBNAME=Build
AGENT_JOBSTATUS=Succeeded
AGENT_MACHINENAME=BUILDMACHINE
AGENT_NAME=BUILDMACHINE
AGENT_OS=Windows_NT
AGENT_ROOTDIRECTORY=C:\Agent\_work
AGENT_SERVEROMDIRECTORY=C:\Agent\externals\vstsom
AGENT_TEMPDIRECTORY=C:\Agent\_work\_temp
AGENT_TOOLSDIRECTORY=C:\Agent\_work\_tool
AGENT_VERSION=2.122.1
AGENT_WORKFOLDER=C:\Agent\_work
BUILD_ARTIFACTSTAGINGDIRECTORY=C:\Agent\_work\2\a
BUILD_BINARIESDIRECTORY=C:\Agent\_work\2\b
BUILD_BUILDID=2036
BUILD_BUILDNUMBER=Database Build_20190708.2
BUILD_BUILDURI=vstfs:///Build/Build/2036
BUILD_CONTAINERID=2281
BUILD_DEFINITIONNAME=Database Build
BUILD_DEFINITIONVERSION=17
BUILD_QUEUEDBY=Smith, John
BUILD_QUEUEDBYID=8c588342-b87a-40cb-9b8c-a0ed10b57a3f
BUILD_REASON=Manual
BUILD_REPOSITORY_CLEAN=false
BUILD_REPOSITORY_GIT_SUBMODULECHECKOUT=False
BUILD_REPOSITORY_ID=$/
BUILD_REPOSITORY_LOCALPATH=C:\Agent\_work\2\s
BUILD_REPOSITORY_NAME=Collection
BUILD_REPOSITORY_PROVIDER=TfsVersionControl
BUILD_REPOSITORY_TFVC_WORKSPACE=ws_2_2
BUILD_REPOSITORY_URI=http://TFSSERVER:8080/tfs/Project/
BUILD_REQUESTEDFOR=Smith, John
BUILD_REQUESTEDFOREMAIL=John.Smith#Mailinator.com
BUILD_REQUESTEDFORID=7a588222-b66a-40ee-9b2a-a0ba10b12a3f
BUILD_SOURCEBRANCH=$/Collection/Project/Code
BUILD_SOURCEBRANCHNAME=Code
BUILD_SOURCESDIRECTORY=C:\Agent\_work\2\s
BUILD_SOURCEVERSION=9811
BUILD_SOURCEVERSIONAUTHOR=Smith, John
BUILD_SOURCEVERSIONMESSAGE=Added missing permission
BUILD_STAGINGDIRECTORY=C:\Agent\_work\2\a
You can list all Environment Variables with the following command:
get-childitem ENV:\
I am assuming you could create a simple build job that executes this and then look at the console output to determine what the name is of the Environment Variable you need.
I'm currently facing a problem with this team of 4.
Using binaries I downloaded on kiska's site. I'm able to compile cobol to C and run it with cobcrun or compile it to an executable. However I can 't get opencobol to find the postgres commands.
Here is the strat of my cobol script :
identification division.
program-id. pgcob.
data division.
working-storage section.
01 pgconn usage pointer.
01 pgres usage pointer.
01 resptr usage pointer.
01 resstr pic x(80) based.
01 result usage binary-long.
01 answer pic x(80).
procedure division.
display "Before connect:" pgconn end-display
call "PQconnectdb" using
by reference "dbname = postgres" & x"00"
by reference "host = 10.37.180.146" & "00"
returning pgconn
end-call
...
the call PQconnectdb fail with module ont found : PQconnectdb
I noticed that if i rename the libpq.dll the error message change to can't find entry point. So at least I'm sure it can get my dll.
After digging into the code of the call method of the libcob library. I found it it was possible to pre load some dll using an environment variable COB_PRE_LOAD but sitll no results.
Here is what look the script to compile the cobol :
call "C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\bin\amd64\vcvarsamd64.bat"
set COB_CONFIG_DIR=C:\OpenCobol\config
set COB_COPY_DIR=C:\OpenCobol\Copy
set COB_LIBS=%COB_LIBS% c:\OpenCobol\libpq.lib
set COB_LIBRARY_PATH=C:\OpenCobol\bin
set COB_PRE_LOAD=C:\OpenCobol\libpq.dll
#echo on
cobc -info
cobc -free -o pgcob -L:"C:\OpenCobol" -llibpq.lib test_cobol\postgres.cob
call cobcrun pgcob
I don't see anything missing, I'm using the 64-bit binaries from kiska's site and use the 64-bit cl.exe from Visual Studio, Postgres is a 64 bit version too (checked with dependencyChecker).
I even tryed to compile the generated C from Visual Studio, same result, but I may miss something, I'm pretty rotten in C and never really had to manage DLL or use Visual Studio.
What am I missing ?
COB_PRE_LOAD doesn't take any path or extension, see the short documentation for the available runtime configurations. I guess
set COB_LIBRARY_PATH=C:\OpenCobol\bin;C:\OpenCobol
set COB_PRE_LOAD=libpq
Will work. You can omit the C:\OpenCobol\bin if you did not placed any additional executables there.
If it doesn't work (even if it does) I'd try to get the C functions resolved at compile time. Either use
CALL STATIC "PQconnectdb" using ...
or an appropriate CALL-CONVENTION or leave the program as-is and use
cobc -free -o pgcob -L"C:\OpenCobol" -llibpq -K PQconnectdb test_cobol\postgres.cob
From cobc --help:
-K generate CALL to <entry> as static
In general: the binaries from kiska.net are quite outdated. I highly suggest getting newer ones from the official download site or ideally build them on your own from source, see the documentation for building GnuCOBOL with VisualStudio.
I am trying to run ReSharpers command line tool InspectCode.exe. It's running fine doing it's job with the expected output.
However after my earlier attempt to get plugins to work, this time with the new version it is supposed to be supported. There is a switch in the command line interface that allows to specify the extension you want to use.
/extensions (/x) – allows using ReSharper extensions that affect code analysis. To use an extension, specify its ID, which you can find by opening the extension package page in the ReSharper Gallery, and then the Package Statistics page. Multiple values are separated with the semicolon.
But I cannot get it to work properly. I cannot even provoke any reaction to the /x switch at all. No matter how or what I pass, I get no feedback from the executable and the output is identical. I don't even get an error message when passing obvious garbage.
I tried the following commandlines for the exact same result:
inspectcode.exe /o="rcli.xml" /swea /x="ReSharper.StyleCop" "my.sln"
inspectcode.exe /o="rcli.xml" /swea /x=ReSharper.StyleCop "my.sln"
inspectcode.exe /o="rcli.xml" /swea "my.sln"
inspectcode.exe /o="rcli.xml" /swea /x=ABCDEFG "my.sln"
Result
JetBrains Inspect Code 9.1.1
Running in 64-bit mode, .NET runtime 4.0.30319.18444 under Microsoft Windows NT
6.1.7601 Service Pack 1
Enabled solution-wide analysis according to Inspect Code command line Setting.
Analyzing files
[files]
Inspection report was written to rcli.xml
What am I doing wrong? How to get extensions to work?
I already tried the R# forums, but it took them more then 24h to approve my post and so far I'm not sure someone else even read it.
Unfortunately, the support for extensions was dropped in 9.0 due to the refactorings in the "ReSharper platform". I hope that JetBrains will bring it back soon.
See RSRP-436208.
This is a late answer that might help future readers (like myself). Currently inspectcode.exe will automatically look for and use any NuGet packages that are in the same folder as the executable (source).
Example for CleanCode extension:
if you have a R# instance on some machine and install the extension, it will be placed in C:\Users\{user}\AppData\Local\JetBrains\plugins\MO.CleanCode.5.6.15
copy MO.CleanCode.5.6.15.nupkg and paste it next to inspectcode.exe
when running inspectcode with verbosity = VERBOSE, the extension should appear in the Zones list:
$cmd = "..\JetBrains.ReSharper.CommandLineTools.2019.3.4\inspectcode.exe"
$outputFile = "..\Output\$($outputName).xml"
& $cmd -o="$outputFile" $sln --verbosity=VERBOSE
Zones: (52pcs)[CodeInspectionPageImplZone, DaemonEngineZone,
DaemonZone, IAmd64CpuArchitectureHostZone, IAspMvcZone,
IBatchToolEnvironmentZone, IClrImplementationHost Zone,
IClrPsiLanguageZone, ICodeEditingOptionsPageImplZone,
IConsoleEnvironmentZone, ICppProductZone, ICpuArchitectureHostZone,
IDocumentModelZone, IEnvironmentZone, IHostSolutionZone,
IInspectCodeConsoleEnvironmentZone, IInspectCodeEnvironmentZone,
IInspectCodeZone, ILanguageAspZone, ILanguageBuildScriptsZone,
ILanguageCppZone, I LanguageCSharpZone, ILanguageCssZone,
ILanguageHtmlZone, ILanguageIlZone, ILanguageJavaScriptZone,
ILanguageMsBuildZone, ILanguageNAntZone, ILanguageProtobufZone, ILa
nguageRazorZone, ILanguageRegExpZone, ILanguageResxZone,
ILanguageVBZone, ILanguageXamlZone, INetFrameworkHostZone, INuGetZone,
IOperatingSystemHostZone, IProjectMode lZone,
IPsiAssemblyFileLoaderImplZone, IPsiLanguageZone,
IPublicVisibilityZone, IRdFrameworkZone, IRiderModelZone,
ISinceClr2HostZone, ISinceClr4HostZone, ITextContro lsZone,
IToolsOptionsPageImplZone, IWebPsiLanguageZone, IWindowsNtHostZone,
PsiFeaturesImplZone, ReplaceableByIntelliJPlatformZone, SweaZone]
Packages: (23pcs)[JetBrains.ExternalAnnotations,
JetBrains.Platform.Core.Ide, JetBrains.Platform.Core.IisExpress,
JetBrains.Platform.Core.MsBuild, JetBrains.Platform. Core.Shell,
JetBrains.Platform.Core.Text, JetBrains.Platform.Interop.CommandLine,
JetBrains.Platform.Interop.dotMemoryUnit.Framework,
JetBrains.Platform.Interop.dotMe moryUnit.Interop.Console,
JetBrains.Platform.Interop.dotMemoryUnit.Interop.Ide,
JetBrains.Platform.RdProtocol, JetBrains.Psi.Features.Core,
JetBrains.Psi.Features.Cpp .Src.Core, JetBrains.Psi.Features.src,
JetBrains.Psi.Features.Tasks, JetBrains.Psi.Features.UnitTesting,
JetBrains.Psi.Features.Web.Core, JetBrains.ReSharperAutomatio
nTools.src.CleanupCode,
JetBrains.ReSharperAutomationTools.src.CommandLineCore,
JetBrains.ReSharperAutomationTools.src.CommandLineProducts,
JetBrains.ReSharperAutomat ionTools.src.DuplicatesFinder,
JetBrains.ReSharperAutomationTools.src.InspectCode, MO.CleanCode]
Installer is installed typically using GUI or console, we need unattended installation capability as well. Running the installer like this (in Linux):
myapp -q -c -varfile myfile.var
Installer installs the software successfully. Problem is it ignores some variables (not all variables). It doesn't read values for zServerPort$Long and zShutdownPort$Long variables and instead applies the default values configured in application.
Varfile is provided below
#install4j response file for Sw 4.6
#Mon Aug 11 19:55:46 PDT 2014
sys.adminRights$Boolean=true
choiceIsLicenseSelected=true
zDBUserName=user
zLaunchDesktopPostInstall$Boolean=false
zDBPassWord=password
sys.languageId=en
sys.installationDir=/opt/mydir
zServerPort$Long=85
zLicenseFilePath=/home/mydir/Desktop/license.lic
zMysqlPath=/usr/bin/mysql
zMysqlCnf=/etc/mysql/my.cnf
zDbPort$Long=3306
choiceInstallDir=/opt/mydir
zShutdownPort$Long=8015
zServerPort, zShutdownPort, choiceInstallDir, zMysqlPath are all installer variables. Reordering the variables didn't work either. Is the problem due to data type being Long ?
Is there a way to pass the values of these two variables zServerPort, zShutdownPort in some other way ?
Other idea am thinking is whether if the installer can know that it is being run in unattended mode and read these variables from command line ?
Most likely, the defaults are applied with a code snippet and not through the initial values of form components.
In those code snippets (i.e. in a "Run script" action"), you have to check whether the value is already defined or not. For example:
if (context.getVariable("variableName") != null) {
context.setVariable("variableName"), 100L);
}