I am unable to unzip the file using VSTS git.
I have tried using unzip, extract file, unzip file but none shows the unzipped file after the build is successfully run
Refer to these steps below to push unzipped files to git repository:
Go to Admin page of that team project (https://{account}.visualstudio.com/{project name}/_admin/_versioncontrol?repoGroup=true&_a=security)
Select corresponding repository
Select Project Collection Build Service (xxx) user and change Contribute permission to Allow
Edit build definition, select the Phase and check Allow scripts to access OAuth token option
Upzip zip files to a directory task: Zip files to unzip: $(System.DefaultWorkingDirectory)\cicdadf.zip; Upzip to path:$(System.DefaultWorkingDirectory)
Command line task: Tool: git; Arguments: config --global user.email you#example.com. Working folder: $(System.DefaultWorkingDirectory)
Command line task: Tool: git; Aeguments: config --global user.name "Your Name"; Working folder: $(System.DefaultWorkingDirectory)
Command line task: Tool: git; Arguments: add cicdadf/**; Working folder: $(System.DefaultWorkingDirectory)
Command line task: Tool: git; Aeguments: commit -m "add unzipped files"; Working folder: $(System.DefaultWorkingDirectory)
Command line task: Tool: git; Aeguments: push https://test:$(System.AccessToken)#{account}.visualstudio.com/{team project}/_git/{respository} HEAD:master; Working folder: $(System.DefaultWorkingDirectory)
Make sure that you have added path variables correctly. The default relative path is the folder where all sources for the build definition are synced. You can go thought other directories/files on the build agent by using full paths or variables in the path. All input boxes for paths do accept variables. For example the source directory is: $(Agent.BuildDirectory)\s. Or use your own variables for the build/release pipeline in the paths.
Reference:https://marketplace.visualstudio.com/items?itemName=petergroenewegen.PeterGroenewegen-Xpirit-Vsts-Build-Zip
Related
I am implementing a gitlab-ci.yml for my project . in this yml file I will need to execute a script.py file . this script.py is located on a differnet project , Is there anyway to include this python script without uploading it to my project?
Something like:
include: 'https://gitlab.com/khalilazennoud3/<project-name>/-/blob/main/script.py
There's no way to 'include' a file that isn't a Pipeline definition template, but you can still grab that file. The way I'd do it is to add a second Pipeline job in a prior stage to clone that other repository, then upload the file you need as an artifact. Then in the job where you need the file, it will have the artifact available.
Here's an example pipeline with just these two Jobs:
stages:
- "Setup other Project Files" # or whatever
- Build
Grab Python Script from Other Repo:
stage: "Setup other Project Files"
image: gitscm/git
variables:
GIT_STRATEGY: none
script:
- git clone git#gitlab.example.com:user/project.git
artifacts:
paths:
- path/to/script.py.
when: on_success # since if the clone fails, there's nothing to upload
expire_in: 1 week # or whatever makes sense
Build Job:
stage: Build
image: python
dependencies: ['Grab Python Script from Other Repo']
script:
- ls -la # this will show `script.py` from the first step along with the contents of "this" project where the pipeline is running
- ./do_something_with_the_file.sh
Let's go through these line by line. For the first job:
We're using the Git image since all we need here is git
The GIT_STRATEGY: none variable tells the Gitlab Runner not to clone/fetch the project the pipeline is running for. This is super useful if the job is doing things like sending notifications to Slack, hitting another API, etc.
For the script, all we do is clone the other project so that we can upload the file as an artifact.
For the second job:
Use whatever image you're using for this job as normal
The dependencies keyword controls which artifacts from previous stages will be 1) required and 2) downloaded for this specific job. By default, all available artifacts are downloaded for all jobs. This keyword controls that since we only need the script.py file.
In the script we just make sure that the file is present, which is just a temporary thing anyway, then you can use it however you need to.
We have jenkins Windows 10 CI builder.
Our project has submodule, which I want to "git submodule update --init --recursive".
This command is called from cmake script, but even if one enables submodule processing the error will be the same:
C:\Program Files\Git\mingw64/libexec/git-core\git-submodule cannot be used without a working tree.
Current setup copies all files of project from Ubuntu jenkins is run on( the setup is not known for sure and I started studying Jenkins from bottom ) and puts them into Windows CI builder into Pull_Request_Builder_Winx64 folder.
Tried to run git manually from this folder: result is the same
Tried running update manually on the same project that is downloaded with git clone, it works.
Please help find the source of the issue, thanks in advance
The issue was the symlink in the path to workspace( C:/jenkins/workspace, "workspace" is symlink here that points to R:/workspace )
Solution: Changed remote root directory in jenkins node configuration, so it contains no symlinks( new path: R:/jenkins, path to workspace will be R:/jenkins/workspace )
I've created a release on Azuredevops with a Command Line Task.
The script is really simple :
Unzip the artifcats and move it to another folder.
But owner's folder is not the same between the Agent Deployment and the repository.
I add chmod 777, it's works, but is not the best answer.
Do you have another solution ?
AzureDevops Release - Command Shell “do not have permissions”
Indeed, to unzip the artifcats and move it to another folder, we could use Extract Files task to complete this:
Extract Files task
Use this task in a build or release pipeline to extract files from
archives to a target folder using match patterns. A range of standard
archive formats is supported, including .zip, .jar, .war, .ear, .tar,
.7z, and more.
BTW, there is an extension to Unzip a directories Zip and unzip directory build task
Hope this helps.
The current zipped result looks like this:
zipped_dir -> folder -> root_folder -> some files
I would like it to function like this command:
cd folder; zip -r ../zipped_dir.zip *
desired result:
zipped_dir -> root_folder -> some files
Jenkins version 2.72, File Operations plugin 1.6.
Source Code Management: Git
branches to build: **/tags/production/**
build triggers: Poll SCM
File operations
file copy :
include pattern: application/**
Exclude File pattern: <blank>
Target Location: ${GIT_BRANCH}
file zip:
Folder Path: ${GIT_BRANCH}
burnettk had the answer to the question.
post answer, jenkins was installed on windows and required MinGW for the zip command.
http://sourceforge.net/projects/mingw/files/Automated%20MinGW%20Installer/mingw-get-inst/
Make sure you have MinGW (usually C:\MinGW\msys\1.0\bin) in the Path environment variable.
install these packages.
mingw-get install msys-unzip msys-wget msys-zip
It seems restarting the jenkins service made it recognize the path addition.
jenkins could then use the zip command.
I am doing the following steps:
dotnet restore
dotnet publish
octopusDeploy: Push packages
The second step creates a 'published-app' folder and the third step is meant to take that and create a .zip file and send it to the Octopus server.
The third step is connecting to the Octopus server but gives the error:
Running command: octo.exe push --server http://server.com/ --apikey SECRET
Pushing packages to Octopus server
Please specify a package to push
I am following this https://stackoverflow.com/a/38927027 so my third step has:
%teamcity.build.workingDir%/published-app/**/* => App.zip
Any ideas why the zip file is not being created?
Not sure if you ever got this working for yourself, however just in case it helps anyone we recently came across the same issue deploying an AspNetCore 2.0 web application running on net471 being built by TeamCity 2017.1.4 (build 47070).
After some tinkering I noticed that the "OctopusDeploy: Create and Push Packages" build step ran at our git checkout root directory, so I ending up having to use the following values for the "Package path patterns"
%ProjectDirectory%/published-app/**/* => %ProjectName%.%GitVersion.NuGetVersion%.zip
NB: %ProjectDirectory%, %ProjectName% and %GitVersion.NuGetVersion% are build parameters we have manually defined elsewhere in the build process that TeamCity can replace. %ProjectDirectory% is simply the application's source directory relative to the root of the git checkout i.e. WebApplication1 so the full path would be <full checkout path>/WebApplication1
Another gotcha that we experienced was that at the time of writing the combination of TeamCity and octo.exe (from Octopus.TeamCity v4.15.10) didn't like creating nupkg files, so make sure you try to produce a ".zip" file. In the error instances we would receive the following error:
Error from Octo.exe: Cannot run program "C:\BuildAgent\temp\buildTmp\octo-temp\3.0\octo.exe" (in directory "C:\BuildAgent\work\4e62985fa616fa1f"): CreateProcess error=206, The filename or extension is too long