I am trying to have a CI/CD pipeline for my project for which the output of the development is multiple xaml files.
I am trying to build a pipeline in Azure Devops tool. For build pipelines we have to select a task (for eg: for powershell scripts there is a powershell task) . Since our project files are xamls , what could we select here and complete our build pipeline?
Basically what are the build activities(like sonarQube and HPFortify for java project) that we can do on xaml files ? If there is none, can I bypass and have an empty build so that we can enter the release pipeline without much build checks.
We dont need to package it into a separate package. It can remain as xaml files after the build and the CD pipelines can deploy it to a folder in the server.
If your build artifact is just a bunch of XAML files then simply use a copy task to copy these to $(Build. ArtifactStagingDirectory) and then use a publish drop task to take the contents of $(Build. ArtifactStagingDirectory) and store it on the server and you're done.
You don't have to have a build task you just need the files required for your release which the above couple of steps will do nicely.
Related
For example, project A generates two artifacts processor.exe and t.txt. Then in project B, can I add a build step to execute processor.exe t.txt?
I know there are two Runner types(.NET Process Runner and Command Line) that can execute programs. But how to get the paths of these artifacts?
Yes, I think it should be possible to run with Command Line runner *.exe file generated by other build.
You just have to make sure that build agent which runs Project A outputs these artifacts to place where build agent which runs Project B has access (in case if you have single agent it's not a concern obviously). And probably placing these artifacts into agent's working directory is not the best place because it can be cleared by doing clean checkout from VCS. Just choose some generic directory on the server and specify it for artifact output in Project A and then for Command Line runner in Project B.
I have TeamCity installed on centos. I have only one Linux BuildAgent for now. My build configuration execute a maven script and using ant upload WAR artifact to Windows Server on FTP. After this step i have to execute BAT file on remote Windows Server. I read that i can do this using psexec/RemCom, but i can't understand how i can do this in TeamCity? Build Step or different Build Configuration should contain steps to execute psexec/RemCom or i can insert Build Step into existed Build Configuration?
Single build configuration could potentially consists of multiple build steps. Think of them as a actions you would like to do. So I suppose that right now you have a maven step in your build configuration. I would suggest you to add Command Line step, where you can do what ever you want -- it's like bash/batch script. You can put script contents directly to the build step, or you can write script and execute it.
But as you mentioned that you have CentOS, it could be you have to do extra configuration on the build agent for PsExec to be available.
I am working on continuous integration project to auto build and deploy ETL workflow and Autosys jil file to target environment.
We are using Perforce P4 for source code repository and Nexus for artefacts repository. Both ETL and Autosys applications are hosted on linux server.
- Developers extract workflow in the form of xml using Repository Manager from Informatica and check-in to source repository in Perforce.
- Developers extract jil file of Autosys job and check-in to source repository in Perforce.
Requirement:
As part of CI process, when developers check-in their code to source repository build process should get triggered and create artefacts of checked-in code and copy to artefacts repository.
Deployment process should get automatically trigger when it find any new artefacts and deploy artefact to target environment.
I would highly appreciate if someone helps me to know:
build and deployment steps
requirement of manifest file
Regarding build/deployment steps its nothing more than:
open build configuration->build steps
create new step in e.g. following way:
Runner type: command line
step name: that_one_from_autosys
working directory: %system.autosys.home%
command executable: run_autosys_.bat
Please check this article, I fully support the author.
You should have Jil templates and Environment contexts (+ other variables).
Than you need to have script that will generate Jil files for each Environment using templates and Env context.
Upload generated Jils to Artifact repository with sufficient version number.
Deploy Jil files using script that will operate with Autosys CLI commands. For instance, you need to stop running jobs, load BOXs before JOBs etc..
I am trying out TeamCity for our CI.
We have a build step running NUnit for unit test and dotCover for code coverage. The process went through fine, but im just wondering if it is possible to export the Build Log and the dotCover's CoverageReport.xml to a predefined directory on the local machine.
or maybe even export all the artifacts and reports used in the build to a local folder.
Just add a build step ( command line ) that will copy over the reports that you need to the desired location locally.
i'm new to world of continuous integration and software developement.
I wanted to try hudson so i installed it on my ubuntu machine and created a new job. i pointed it to an open source project's svn (keepassx) just to try.
Hudson downloaded everything from the repository and marked blue for successful build.
aren't i suppose to be able to execute the software now somehow ? i thought once it is built i can run it, but i can't find any executable in the project's home page under hudson user home dir.
thanks.
A Hudson/Jenkins build breaks down into three steps:
update source code in workspace
run build
publish build artifacts
It sounds like you've got step 1 covered.
If the project you linked to has instructions for building (ant, maven, etc.), you can enter these as build steps into the "Build" section of the project configuration.
You can then take the resulting files ("artifacts"--jar, exe, so, bin, whatever) and publish these using the "Post-build Actions", or if necessary you can grab them directly from the workspace filesystem.
Assuming the build artifact was an executable, you could then run it after downloading it from Hudson, or make a build step or post-build action which moved it into the appropriate location and ran it.
It helps to run the build locally before trying to get Hudson to handle it--then you know what the build steps are, and what the final build artifacts are.
How would jenkins/hudson know how to 'execute' some arbitrary package that you told it to download and build? It's up to you to write a program or script to run what you want to run, and then make a downstream job (for example) to do so.