How to convert Windows path to UNIX path - github-actions

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.

Related

Services and env in manifest file?

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

Setting mem configure option in TCL build script

I need to build Activestate TCL for Ubuntu 18.04 with memory option enabled, "--enable-symbols=mem flag to the configure script" but there is no configure script in my download, only these, which don't have a "configure" line in them.
license-at8.6-thread.
update_check
komodo_download
payload
README-8.6-thread.txt
pdemos
install_welcome.txt
install.tcl
install.sh
install_lib.tcl
install_images
MANIFEST_at8.6.txt
install_data.tcl
Can someone describe how to add the switch described above for Ubuntu?
.
In order to set the mem option, you'll need to compile Tcl from source. To do that you'll need to get a C build chain (especially a C compiler such as gcc or clang, and make to act as a build orchestrator) and the Tcl (and Tk) source code for the version you want to build. The official location for releases of Tcl sources is on SourceForge:
https://sourceforge.net/projects/tcl/files/Tcl/
Pick the version you need and the download package you prefer (ZIP or compressed Tar archive).
Once you've downloaded and unpacked the Tcl code, change into the appropriate directory within the distribution (e.g., unix for Linux builds) and run the configure script inside; it's that script that you pass the --enable-symbols=mem option to.
ActiveTcl is essentially built the same way (except without symbols at all; it's a production distribution after all). It's main distinguishing feature is that it is set up with access to lots of extra packages to go with it. The same goes for most Linux distributions' own tcl packages. They're all production distributions and aren't configured for memory debugging precisely because that adds a lot of overhead to the code (both time and space).

'ALGOLIA_API_KEY' not recognized as an internal or external command

I am trying to run algolia for the first time but it seems that there is something wrong with my environment. I followed the detailed explanation here https://community.algolia.com/jekyll-algolia/getting-started.html.
I installed and configured everything that is needed from the previous steps but when I run the command
ALGOLIA_API_KEY=xxxxxxxxxxxxxx bundle exec jekyll algolia
I get an error:
'ALGOLIA_API_KEY' is not recognized as an internal or external command,
operable program or batch file.
I have been rereading the documentation for both jekyll and angolia but couldn't find anything that could be helpful.
Since you're running on Windows, you cannot set an environment variable for your command like you can do on UNIX.
As advised in this question, Setting and using variable within same command line in Windows cmd.exe, I believe you could use
set ALGOLIA_API_KEY=xxxxxxxxxxxxxx && bundle exec jekyll algolia

Running Expect script on windows

I've the expect script running on linux which I want to run it on windows. I've added
#!/bin/sh
# \
exec tclsh "$0" ${1+"$#"}
package require Expect
lines as well at the start. I'm getting 'can't find package Expect' error. where can I get that?
Expect for Windows is done by ActiveState as part of ActiveTcl (no charge for the 32-bit version), which is highly recommended as the definitive batteries-included build of Tcl on the Windows platform. (I'm not sure if Expect for Windows is part of the Community Edition; I'm on a different platform so checking is a little awkward.)
Be aware that there are some substantial differences between Unix and Windows under the covers, and Expect is an extension package that gets very deep into the details. It hides nearly all the horrible differences, but not all; advanced scripts may need quite a bit of extra work to port. Also, some Windows executables (notably telnet.exe) can't be wrapped by Expect because they're marked as special system files, and GUI apps can't be wrapped at all. There are often good alternatives for subordinate processes though.

Is it possible to specify Windows shell to use when specifying hooks in Mercurial?

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