I am trying to automate building some dependencies on my Win machine, throught Powershell scripting. I am just fetching sources from Github, building throught CMake etc. For one of the dependencies, I need to apply a patch from a pull request.
In my script, I am creating the asm.patch file automatically. This is the correct patch file. If I apply this patch on a Unix environment through patch < asm.patch, everything works fine. I have no way of applying this patch file on my Powershell script though.
The thing I tried, I installed GnuWin32 native port of patch. In my script, I am calling it like patch -i asm.patch because Powershell does not let me to use token <. It calls the patch command correctly. But GnuWin32 patch port opens up a dialog related to permissions. So it is not useful for my automation needs.
Question is, what is the standard way of applying .patch file on Powershell scripts?
git apply worked eventually
I was working with a temporary, generated project in a git 'ignored' folder. The patch was oriented to the folder of the temporary project but because of the surrounding git project all I got was Skipped patch.
Using git init <TEMP_PROJECT_FOLDER> allowed the patch to be applied although this may not be necessary for you.
Other tips:
--directory resulted in error: invalid path because PowerShell's tolerance of / in paths is only superficial (I gather). So need to change current working directory.
--verbose helps but isn't comprehensive
Other options from #Moerwald: --ignore-space-change --ignore-whitespace --whitespace=nowarn
Is git apply an alternative? If so, try:
invoke-expression "git apply --ignore-space-change --ignore-whitespace --whitespace=no warn file.patch
Related
I am trying to do user authentication if a pull request contain changes in certain folders. I am intending to do this even before GitHub actions are triggered using pre-build script. I am able to access the user information using the environment variable github_event_path and extract author using jq.
Now I am not able to find a way to get changed files(thus finding out what folder a change is made, based on the absolute path) in this pre-build shell script. I tried using ${{steps.files.outputs.all}} that is used in getting the changed files in GitHub actions. I think steps is not accessible in pre-build shell scripts as I got bad substitution error.
I have a GitHub action workflow file that is running fine, but recently warnings about ‘set-env’ and ‘add-path’ deprecation have been brought to my attention. The fix suggested by GitHub is to use “Environment Files”; I.e. pipe values into a file managed by a GITHUB_ENV file descriptor.
My question is : Is GitHub asking me to replace the “env” block of my workflow with a step containing commands of the form ‘echo “{name}={value}" >> $GITHUB_ENV’?
I have to also ask why this is necessary, since I think it is lame, but that is really beside the point.
From my experience using python with GitHub actions, this is an issue with actions/setup-python versions 1.1.1 and earlier. You probably have a line in your workflow that reads:
uses: actions/setup-python#v1.1.1
If you upgrade to version 2 of setup-python, there will be no warning. Just change the line above to the following:
uses: actions/setup-python#v2
In order to demonstrate, the log of my v1.1.1 workflow shows the warnings you mentioned, but the warnings are resolved by using version 2
I have to also ask why this is necessary
This was announced in early Oct. 2020 this month, and pointed to a moderate security vulnerability
The #actions/core npm module addPath and exportVariable functions communicate with the Actions Runner over stdout by generating a string in a specific format.
Workflows that log untrusted data to stdout may invoke these commands, resulting in the path or environment variables being modified without the intention of the workflow or action author.
For now, users should upgrade to #actions/core v1.2.6 or later, and replace any instance of the set-env or add-path commands in their workflows with the new Environment File Syntax.
Workflows and actions using the old commands or older versions of the toolkit will start to warn, then error out during workflow execution.
So:
echo "FOO=BAR" >> $GITHUB_ENV
echo "/Users/test/.nvm/versions/node/v12.18.3/bin" >> $GITHUB_PATH
That is why a GitHub Action like actions/setup-python has a recent PR 138 in order to uses Environment files to communicate with the Runner.
But if you are using any other workflow based on actions/core, you need to upgrade said actions/core version as soon as possible.
We are using VSTS for CI and CD in my team, we got over 40 repositories which are separated projects. but all of them have to run the same PowerShell script in one of their Build steps.
the PowerShell file is bigger too big to be kept as the inline script, so we need to save it inside a file. obviously, I got a copy of the PowerShell file in each repository.
Problem:
Now whenever I need to update the script, then I end up to update it in every repository, which is over 40 at the moment.
I think there should be a better approach. Is there any way that I can put my script in one single repo (a repo dedicated to holding the script) then I use it within each build, therefore we I need to update it I only need to update it once.
There are a few options.
My general recommendation is to publish the script as a package (NuGet or otherwise) and restore it during your application builds. This allows consumers to stay "pinned" to a known-good, known-working version, and update on a schedule that works for them.
Another option is to add a submodule to each repository that requires the script dependency, then initialize the submodule during the build process.
A third option is to turn the shared script into a VSTS build task or extension. This is extensively documented and easily located so I won't belabor the point by including instructions for doing that here.
You can add a git repository to store your powershell file.
Then add a build step to get you file from that repository during build and use it.
I have an MVC4 + EF4.0 .NET 4.5 project (say, MyProject) I'm able to run the project locally just fine. When I FTP deploy it to Azure Websites (not cloud service) it runs fine too. However, if I do a GIT deploy, the site 'runs' for the most part until it does some EF5.0 database operations. I get an exception Unable to load the specified metadata resource.
Upon debugging I noticed that if I:
GIT deploy the entire MVC4 project (as before)
FTP in and then replace bin\MyProject.dll with the bin\MyProject.dll file that I just built locally (Windows 8 x64, VS2012, Oct'12 Azure tools) after the GIT push (i.e. same source)
then the Azure hosted website runs just fine (even the EF5.0 database functionality portion).
The locally built .dll is about 5KB larger than the Azure GIT publish built one and both are 'Release' mode. It's obvious that the project as built after the GIT push (inside Azure) is being built differently than as on my own PC. I checked the portal and it's set to .NET 4.5. I'm also GIT pushing the entire solution folder (with just one project) and not just small bits and pieces.
When I load the locally built as well as the remotely built MyProject.dll files, I noticed the following difference(FrameworkDisplayName)
local: System.Runtime.Versioning.TargetFrameworkAttribute(".NETFramework,Version=v4.5", FrameworkDisplayName = ".NET Framework 4.5"),
remote: System.Runtime.Versioning.TargetFrameworkAttribute(".NETFramework,Version=v4.5", FrameworkDisplayName = ""),
Anyone knows why this is happening and what the fix might be?
Yes, this is a bug that will be fixed in the next release. The good news is that it's possible to work around it today:
First, you need to use a custom deployment script, per this post.
Then you need to change the MSBuild command line in the custom script per this issue.
Credit goes to David above for the pointers and hints. I voted him up but I'll also post the exact solution to the issue here. I've edited my original post because I found there was a major bug that I didn't notice until I started from scratch (moved GIT servers). So here is the entire process, worked for me.
Download Node.JS (it's needed even for .NET projects because the GIT deploy tools use it)
Install the azure-cli tool (open regular command prompt => npm install azure-cli -g)
In the command prompt, cd to the root of your repository (cd \projects\MyRepoRoot)
In there, type azure site deploymentscript --aspWAP PathToMyProject\MyProject.csproj -s PathToMySolution.sln (obviously adjust the paths as needed)
This will create the .deployment and deploy.cmd files
Now edit the deploy.cmd file, find the line starting with %MSBUILD_PATH% (will be just one)
Insert the /t:Build parameter. For example:
[Before] %MSBUILD_PATH% <blah blah> /verbosity:m /t:pipelinePreDeployCopyAllFilesToOneFolder
[After] %MSBUILD_PATH% <blah blah> /verbosity:m /t:Build /t:pipelinePreDeployCopyAllFilesToOneFolder)
Push to GIT (check the GIT output if everything went ok)
Browse to your website and confirm it works!
I'll be glad when it's fixed in the next revision so we won't maintain the build script
Creating a patch is very easy in SubVersion, With Tortoise, you right-click and select Create Patch. But for the life of me, I can't find this functionality in TFS. Is this possible?
If not, what's the standard way to submit patches in open source TFS hosted projects (a la CodePlex)?
tf diff /shelveset:shelveset /format:unified
Edit: This writes to standard output. You can pipe the output to a file.
For more options, see Difference Command.
Because TFS doesn't natively support patch files, the most common thing I see people do on CodePlex is simply zip the modified files and upload the zip. The project coordinator then does a diff against their own checkout.
However since CodePlex also supports TortoiseSVN, more and more people are using that to create their patch files.
I wrote a blog post about a similar issue where I used the TF.exe command and 7Zip to create a TFS patch file that could then be applied on another TFS server or workspace. I posted the the Powershell scripts at Github, which can be used to Zip up any pending changes on one workspace and then apply them to a different server. It would have to be modified to use a changeset instead of pending changes, but that shouldn't be too difficult to accomplish.