I am trying to set up a hook on a remote repository (using hgweb) on a Windows IIS server. The issue I have is that the repository is specified as a UNC path in hgweb's config, and the hook executes cmd.exe using a UNC path which cmd.exe does not support.
Is it possible to specify a different shell to run instead?
As far as I know, you can't tell Mercurial to use a different shell on Windows (but I think you can on a Linux host)
Instead, you could have your hook script call out to a different shell and have that shell execute another script or set of commands. It's messy, but unfortunately Windows isn't know for having great scripting support, especially when compared to *nix-based platforms.
Mercurial hooks can be defined two ways,
as a shell hook (external hook)
as a python hook (in process hook)
if you change it to be a python hook, then you would obviously have the full power of python available to do stuff. Of course there is no reason why you can't write a program in any language and execute it from your external hook as cdeszaq suggests
Related
I'm writing a GitHub Actions workflow that will run on Linux, Windows, and macOS. To avoid redundancy, I want to use the same steps on all platforms as far as possible. This includes UNIX commands like curl and tar that aren't available in PowerShell, the default shell on Windows. So I'm planning to explicitly set the shell to bash on all platforms.
Which brings up the problem: bash expects UNIX paths in commands, but from the documentation, it seems that all environment variables contain platform-specific paths. So on Windows, all environment variables will contain Windows paths. How can I convert them to UNIX paths for use in bash?
Edit: Clarifications:
The paths I'm talking about are environment variables set by GitHub Actions such as GITHUB_WORKSPACE.
For each step of a job, GitHub Actions allows me to explicitly specify the shell to be used. So running bash on Windows in a one-liner in GitHub Actions and doesn't require any installation.
This question is primarily about best practices in GibHub Actions, not about what is possible using bash scripts. If the only way to convert the path is to use a bash script, then #Yahampath's comment answers my question. But I was hoping the GitHub team had thought of a more elegant solution.
I have a web (online calculator for an example) which developed by my fellow tem members. Now they want to deploy in PCF using manifests.
Languages used : python, php and javascipt.
I gone through the docs about pcf with manifest.yml
In that I don't have any idea about services and env.
What is that services and how can I find the services for the above project and also how can I find the environment variables?
And tell whether these fields are mandatory to run the project in PCF.
To your original question:
What is that services and how can I find the services for the above project and also how can I find the environment variables? And tell whether these fields are mandatory to run the project in pcf.
Does your app require any services to run? Services would be things like a database or message queue. If it does not, then you do not need to specify any services in your manifest. They are optional.
Similarly, for environment variables, you would only need to set them if they are required to configure your application. Otherwise, just omit that section of your manifest.
At the end of the day, you should talk with whomever developed the application or read the documentation they produce as that's the only way to know what services or environment variables are required.
In regards to your additional questions:
1)And also I have one more query...like in our application we used python ok! In that we use lots of pacakages say pandas,numpy,scipy and so on...how can I import all the libraries into the PCF ??? Buildpacks will contain version only right?
Correct. The buildpack only includes Python itself. Your dependencies either need to be installed or vendored. To do this for Python, you need to include a requirements.txt file. The buildpack will see this and use pip to install your dependencies.
See the docs for the Python buildpack which explains this in more detail: https://docs.cloudfoundry.org/buildpacks/python/index.html#pushing_apps
2)And also tell me what will be the path for my app name if Java I can enclose jar files
For Java apps, you need to push compiled code. That means, you need to run something like mvn package or gradle assemble to build your executable JAR or WAR file. This should be a self contained file that has everything necessary to run your app, compile class files, config, and all dependent JARs.
You then run cf push -p path/to/my-app.jar (or WAR, whatever you build). The cf cli will take everything in the app and push it up to Cloud Foundry where the Java buildpack will install things like the JVM and possibly Tomcat so you app can run.
what should I do for application devloped using pyhton , JavaScript and php....
You can use multiple buildpacks. See the instructions here.
https://docs.cloudfoundry.org/buildpacks/use-multiple-buildpacks.html
In short, you can have as many buildpacks as you want. The last buildpack in the list is special because that is the buildpack which will set the start command for your application (although you can override this with cf push -c if necessary). The non-final buildpacks will run and simply install dependencies.
3) we were using postgresql how can I use this in pcf with my app
Run cf marketplace and see if there are any Postgres providers in your Marketplace. If there is one, you can just do a cf create-service <provider> <plan> <service name> and the foundation will create a database for you to use. You would then run a cf bind-service <app> <service name> to bind the service you create to your app. This will generate credentials and pass them along to your app when it starts. You app can then read the credentials out of VCAP_SERVICES and use them to make connections to the database.
See here for more details:
https://docs.cloudfoundry.org/devguide/services/application-binding.html
https://docs.cloudfoundry.org/devguide/deploy-apps/environment-variable.html#VCAP-SERVICES
This is the command-line used install MySQL silently,
/quiet
But how to run the MySQL installer unattended with custom settings in the installer?
UPDATE: A newer and somewhat related answer here.
UPDATE: Several stages of answers here. I will leave them all in. The proposed technical solution / workaround moved to the top.
Instance Configuration
The actual configuration of instances seems to have been moved from MySQLInstanceConfig.exe to the installer itself: Where is the MySql 5.6 equivalent of `MySQLInstanceConfig.exe` to edit configuration files? Please try the MySQLInstallerConsole.exe (note: that links to version 8.0, not 5.7) application, sample:
Silent Installation: It seems this console appliation can run the installation silently in
various flavors, making the procedure below optional.
MSI Packages
I did a test run of what I believe was the mysql-5.7.22-winx64.msi file (there are many MSI files embedded in the main one, please see below). My best tip: get on the phone with the vendor to determine if they have actively tried to prevent silent installation. They just might have, and then you might be fighting windmills over time. They should improve this design if you ask me - though it is not the worst I have seen.
By launching the original, large MSI and enabling automatic logging (see section in that link: "Globally for all setups on a machine"), then running through its built-in, custom GUI and kicking off the actual install and then checking the "CommandLine" entry in the actual log file generated in the temp folder - it looks like it sets the following properties: REBOOT, ADDLOCAL, INSTALLDIR, INSTALLLOCATION, ARPINSTALLLOCATION, INSTALL_ROOT, DATADIR. Actual log entry below:
******* Product: C:\ProgramData\MySQL\MySQL Installer for Windows\Product Cache\mysql-5.7.22-winx64.msi
******* Action:
******* CommandLine: REBOOT=ReallySuppress ADDLOCAL=RegKeys,ALWAYSINSTALL,Readme,MISC,Server_Scripts,ProgramMenu,MYSQLSERVER,Client,DEVEL,SharedLibraries,UserEditableDataFiles INSTALLDIR="C:\Program Files\MySQL\MySQL Server 5.7" INSTALLLOCATION="C:\Program Files\MySQL\MySQL Server 5.7" ARPINSTALLLOCATION="C:\Program Files\MySQL\MySQL Server 5.7" INSTALL_ROOT="C:\Program Files\MySQL\MySQL Server 5.7" DATADIR="C:\ProgramData\MySQL\MySQL Server 5.7" ALLUSERS=1
These are in other words the properties set by the custom setup GUI that normally runs the installation process. You should be able to use this procedure for all the embedded MSI files you need to install. Then you simply extract these MSI files that you need from the large MSI and run them in sequence in some fashion, with the command lines you have found. You can also apply transforms if need be.
To state the obvious: this might take you some time to get right as you struggle with pre-requisites and your corporate use case. I'd go for piloting. Find a dynamic team and get your stuff on their test PCs quickly and tell them to give it a trashing asap :-). Chances are you already do, just mentioning it. I for one can never get these things right without some unfortunate, time-consuming iterations.
Summary of procedure:
Enable automatic logging (MSI expert Stefan Kruger's info)
Install via custom setup-GUI with options set as appropriate
Find properties to set in the log file in the %temp% folder.
Log file will have random name, sort by data and open most recently changed log file.
Get hold of the embedded MSI files from the wrapper setup:
Get hold of an MSI tool for viewing / editing MSI files (list towards bottom)
Delete launch conditions from wrapper setup (LaunchCondition table)
Extract content like this: msiexec.exe /a mysql-installer-community-5.7.22.1.msi TARGETDIR=C:\YourFolder
Tha above command kick off an administrative installation - essentially a glorified file extract, but a very good feature of MSI used by application packagers every day
Try to install on a test machine with an msiexec.exe command line based on the properties you found set
Sample:
msiexec.exe /i mysql-5.7.22-winx64.msi REBOOT=ReallySuppress ADDLOCAL="RegKeys,ALWAYSINSTALL,Readme,MISC,Server_Scripts,ProgramMenu,MYSQLSERVER,Client,DEVEL,SharedLibraries,UserEditableDataFiles" INSTALLDIR="C:\Program Files\MySQL\MySQL Server 5.7" INSTALLLOCATION="C:\Program Files\MySQL\MySQL Server 5.7" ARPINSTALLLOCATION="C:\Program Files\MySQL\MySQL Server 5.7" INSTALL_ROOT="C:\Program Files\MySQL\MySQL Server 5.7" DATADIR="C:\ProgramData\MySQL\MySQL Server 5.7" ALLUSERS=1 /QN
And some parameter info:
ADDLOCAL="..." - list of features to install locally
REBOOT=ReallySuppress - prevent spontaneous reboot
ALLUSERS=1 - install per machine
/QN - crucial addition to the command line found in the log file. this makes the install run in silent mode
Unusual MSI Design: I know this is an unusual MSI, but generally you call the vendor or search their website to obtain documentation for deployment such as this and follow the procedure I outline below (let me add the link here too: How to make better use of MSI files) using PUBLIC properties or transforms to modify the installation.
However, I wrote the section below before I did a quick check of this MSI. A quick look revealed a myriad of embedded MSI packages. Not at all good. The MSI also has no GUI, and its administrative installation (file extraction) is blocked with a launch condition. Quite terrible design in fact. You can make an administrative installation by deleting the launch conditions using Orca or an equivalent tool and going:
msiexec.exe /a mysql-installer-community-5.7.22.1.msi TARGETDIR=C:\YourFolder
It seems the idea is that this is a wrapper MSI which will launch a proprietary GUI (.NET based?) that you can then use to install the bits and pieces you need of the MySQL tool suite. It would have been much better if this launcher was a setup.exe built with WiX Burn, Installshield, Advanced Installer or an equivalent tool.
Recommended Procedure: The honest answer is that I don't know. I would call the vendor if possible, check their user forums and do some further googling in general. Most of the embedded MSI files should be possible to install in silent mode, I would hope.
The real-world approach would probably be to extract all the MSI files using the above administrative installation trick, although there must be a reason why they block administative installations - which I am unaware of. Most likely they do not want to support silent installation with options? (give them a call?). Then you take the individual MSI files you need, and see if they will install in silent mode using the approach described here with PUBLIC properties and / or transforms. There are many features in these setups, and you can use ADDLOCAL at the command line to define which ones to install and not. See the linked answer below. However, as I state below as well; feature control is a very complex topic (recommended skim).
Beware of pre-requisite runtime requirements. There may be several, such as the .NET framework and various runtimes. I see several of these being installed by the custom setup GUI.
My original, generic answer below:
MSI: It looks like this installer is in Windows Installer format, in other words an MSI file. You are in luck in the sense that MSI files are very flexible with regards to silent installation and the configration of custom paramenters. It is, however, dependpent on the package being well-designed, which is not always the case.
PUBLIC PROPERTIES and Transforms: I have an ancient answer here on the topic of customizing MSI installations: How to make better use of MSI files (just the first parts, the ending flies a bit off the handle with other topics). As you will see in the linked answer, you essentially set available PUBLIC properties at the command line, or create a transform to customize anything you want in the installer. The latter is what most corporations do for deployment.
Configuration: What properties can be set at the command line (that has any effect), varies between different setups. The setup creator must have made these properties - and built functionality around them in the setup - for them to be configurable. Typical parameterized values would include license keys, URLs to license servers and user and company names and emails and similar. For more substantial changes (such as changing shortcuts or similar), people usually resort to using a transform. You also use the ADDLOCAL property to define which features to install (all other features will not be installed if you specify a value for ADDLOCAL). Feature control is a built-in property of MSI, and you can control feature selection in detail from the command line or via a transform. However, feature control is a very complex topic (recommended skim).
Concrete Sample: As mentioned above you need to set properties and values as appropriate for the setup in question. This means you have to hit the documenation for the setup in question to determine what is "settable" or not.
Some Links:
https://downloads.mysql.com/docs/refman-5.7-en.pdf
https://dev.mysql.com/doc/mysql-installation-excerpt/5.5/en/windows-using-installer.html
I'm looking for a tcpdump binary that runs on openwrt. The website only shows source code that must be built. Anybody point me to a location that contains a prebuild binary? Thanks.
I suggest to set up a working repository, i.e.:
https://downloads.openwrt.org/chaos_calmer/15.05-rc2/x86/generic/packages/base/
You can put the url on your OpenWRT system under /etc/opkg.conf.
Using opkg you do not have to deal with all the dependencies.
opkg update
opkg install tcpdump
If there is no internet connection on the Openwrt system, and there is no local repository deployed, the solution above works as well, but it is more painful and consumes more time.
You find binaries at
http://downloads.openwrt.org/snapshots/trunk/
but you have to use the right one for your hardware plattform
e.g for x86
http://downloads.openwrt.org/snapshots/trunk/x86/packages/tcpdump_4.2.1-1_x86.ipk
The prefered method is to use opkg to install the package
I am setting up a new Hudson task (on WinXP) for a project which generates javascript files, and performs xslt transformations as part of the build process.
The ant build is failing on the XSL transformations when run from Hudson, but works fine when the same build on the same codebase (ie in Hudson's workspace) is run from the command line.
The failure message is:
line 208: Variable 'screen' is multiply defined in the same scope.
I have tried configuring Hudson to use both ant directly and to use a batch script - both fail in Hudson.
I have tried in Firefox, IE6 and Chrome and have seen the same issue.
Can anyone suggest how we can workaround this problem with Hudson?
Problem solved.
Our build is actually dependent on jdk 1.4.2, and Hudson appears to run using 1.6. When I set Hudson to run as a service, it ran as my local user, which meant that it picked up the 1.4.2 JAVA_HOME environment variable - and therefore worked.
I guess another possible solution is to configure Hudson to use 1.4.2 by default.
I would assume this is not an issue with Hudson directly, as it is with the build script and/or the environment itself.
Is your build script relying on certain environment variables being defined, or worse, the job running from within a certain directory structure (i.e. it works if it's run from under /home/mash/blah but not from under another directory like /tmp)? Is the build script making reference to external files by relative paths?
These are the things I would look into. For environment variables, you can tell Hudson to pass these into Ant. For the other issues, you probably want to change your build script. Check the console output provided by Hudson, and maybe set Ant to print verbose/debug messages to get a better idea about the environment/filepaths.