I am having multiple project in rundeck (Version : Rundeck 2.11.4-1)
Project A -> JOB A
Project B -> JOB B
Project C -> JOB C which will call JOB A and Job B.
Project A,B,C having different resource xml .Hence having different value against same properties in resource xml.
So when I am running the JOB C from Project C . Its look up the resource xml of Project C.
What I am looking for is how can I ensure JOB A use Project A resource xml and JOB B use Project B
resource xml even if its actually call from Project C.
I replicated your scenario, and the solution is to update to the latest Rundeck version (3.4.7 at this moment) to use the "Use references job's nodes." capability in the job reference step, this option isn't available on 2.11.x.
In that way, you can achieve your goal.
Alternatively (and as a "dirty" solution) is to call the JobA and JobB individually via Rundeck API from JobC using the inline-script step.
Due to the big gap between 2.11.4 and 3.4.6 I recommend you to create a fresh 3.4.6 instance and import all projects, keys, and nodes. Take a look at this.
Adding key of nodes used in JOB A & JOB B to project C may solve this issue.
First save the keys using "Key Storage Option" then under project settings > Default Node Executors > SSH Key Storage Path Browse to those keys and save.
It may be because of Nodes of job A & B are not accesible by project C.
Related
Should I bundle the source code, build script and deployment script together? In my previous company, they are always bundled together, but there is always a problem that when the company add a new server, they need to change the deployment script and create a new build version, however, there is no change to the source code. I would like to see what is your company practice on the source control, build and deployment.
The best practices for deployment are to have some standard system for that purpose. Usually that system will have a standard way to enumerate what hosts are available and what versions of software are on each host, so any scripts necessary for deployment become agnostic to the machines in use.
Similarly, in many environments, deployment uses a set of standard techniques. For example, it is common to use CI to run tests and then build one or more deployment artifacts, such as a tarball or container, and then all deploys using the same technique use the same deployment method (e.g. unpack the tarball into a directory named after the repository name), so in that case a deployment script may not even be necessary. If you use a standard method and one is necessary, then obviously you should include it in your artifact (which means it's included in the source code) or in the configuration for the deployment system (which should be maintained as repository as well).
As to whether one should include source code depends on whether it's needed. If you're deploying a project in a language like Python or Ruby, then obviously it will be needed. However, if you're deploying a project in a compiled language like Go or Rust, then it probably is not, and your build artifacts will be smaller and easier to work with if you don't include it and just build a binary artifact during CI.
I'm currently working on a ReadyAPI project with a collegue. Our projects have the same resources (same swagger has been used) and we are developing different testSuites.
We have both a testSuite with the basic resources tested unitary and our own testSuites that refer to this testSuite's testCases.
example.
TSuite_common/TCase1 : request1
TSuite_my_Collegue/TCase1 : run TSuite_common/TCase 1 + some processing
TSuite_my_testSuite/TCase1 : run TSuite_common/TCase 1 + some other processing
We want to merge projects in order to have all the testSuites but when I export/import his testSuites, the references to resources are lost, ie. references to TSuite_common/TCase1, altough I have the exact same TSuite_common/TCase1 in my project !
It is not possible to resolve all the links by hand as there are too many of them, is there a particular option that I have to set to do the merge properly ?
Do I have to use groovy scripting ?
thanks in advance
Alexandre
Well finally I found a way to proceed.
In SOAPUI, a 'Run test case step' implies the creation of a reference linked based on the distant test case's uid.
As the TSuite_common/TCase's uid is not the same in my project (destination) and in my colleague's project (source), I had to build a script to play on the exported source/testSuite
This script :
- gets the referenced test case's name from its uid (in the source/TSuite_common)
- gets the corresponding uid from the testcase's name in the destination/TSuite_common (which contains the same APIs as in the source)
- replace the referenced test case's uid with the uid just found
- import the testSuite in myProject
There is no unresolved links
Note that it's finally fairly easy as the testSuites imported have a different name from mine.
Next step : merge an existing testSuite from another project (!)
I have a web application that reads from a file. My application is represented as a node and file as an artifact. Can I use dashed arrow to represent their relationship ?
I never used artifacts as you want but it seems legal.
Artifact (p654) : An Artifact represents some (usually reifiable) item of information that is used or produced by a software development process or by operation of a system. Examples of Artifacts include model files, source files, scripts, executable files, database tables, development deliverables, word-processing documents, and mail messages.
A log file is produced by an operation of the system, I guess. Guys, what do you think ?
And there a stereotype in the standard profile: «Create» : A usage dependency denoting that the client classifier creates instances of the supplier classifier. (p 678)
So if you want to model that your wbe server creates an instance of LogFile, the following schema should do the job.
More remarks:
the web server is an execution environment deployed on a node.
your web application is an artifact running on the execution environment.
That's perfectly ok. You could optionally stereotype the dependency with <<create>>.
I'm trying to use application packages in the way they're described in this
https://learn.microsoft.com/en-us/azure/batch/batch-application-packages
But I keep getting an error saying
application path not found.
Any ideas what could be wrong? Or
How do application packages work in the background, that might help me debug the error?
EDIT: I am trying to add an application package specific to my job manager task. I added the package as a zip file through Azure portal under the name JobManagerTask and version 1.0. Here is the code I'm using to reference it:
string taskID = "tasktest1";
// Obtain application package that has executables for job manager task
ApplicationPackageReference jobManagerApp = new ApplicationPackageReference { ApplicationId = "JobManagerTask", Version = "1.0" };
// Command Line
string commandLine = #"cmd /c %AZ_BATCH_APP_PACKAGE_JOBMANAGERTASK#1.0%\\JobManagerTask.exe";
// Create a CloudTask
CloudTask oneTask = new CloudTask(taskID, commandLine);
oneTask.ApplicationPackageReferences = new List<ApplicationPackageReference> { jobManagerApp };
// Provide elevated admin access to the task
oneTask.UserIdentity = new UserIdentity(new AutoUserSpecification(elevationLevel: ElevationLevel.Admin, scope: AutoUserScope.Task));
// Could add task resource files if needed here
await batchClient.JobOperations.AddTaskAsync(jobID, oneTask);
Coool, so i created a small barebone app. :) rest details are below and please feel free to ping me if I can helpout further.
so I tried with almost identical code like your's minus couple of flags like userIdentity and seems like I had my sample working fine, I think the error will only happen in case where the application package is not correctly refer'd. like if my *.exe reside in some diff dir structure etc. :)
I thought it will be a good idea to create a vanilla (i.e. from scratch application for you by taking one of the existing samples.) which might give you a chance to quickly take a look and see if you missed anything.
Please feel free to ping me and I will help you out to achieve your coal, I think its something very small like path is wrong etc. (which error message also suggest)
The Application reside here:
https://github.com/Tatsinnit/quick_sample_batchapppkgworking
Detail:
Detail is also there in the Readme for the git but as its a good practice in SO to detail everything here I will copy paste what I have written in readme here for you.
quick_sample_batchapppkgworking
Readme: barebone quick app:
Please note thta this app is nothing but a quick sample made based on the existing sample for DotNetTutorial.
Following code is generated just as a sample code for end to end app package working feature.
• https://learn.microsoft.com/en-us/azure/batch/
• https://learn.microsoft.com/en-us/azure/batch/batch-technical-overview
App Pacakges:
• https://learn.microsoft.com/en-us/azure/batch/batch-application-packages
• https://azure.microsoft.com/en-us/blog/application-packages-and-task-dependencies-now-available-on-azure-batch/
The overview as how it works is fairly simple, when user uploads to adds an application package the package becomes available within node’s working directory (wd). The env var gets created to handle multiple updated versions of the app: (the timestamp is automatically part of the App pkg populated env var you dont need to do anything to handle this.)
set AZ_BATCH_APP_PACKAGE_TEST1#1.0=C:\user\tasks\applications\wd\test1\1.0\2017-07-14T21.45.45.765Z
Hence if user has correct package version all set and node has app pkg they can invoke that from whatever the need is for application package: (something like this)
string taskCommandLine = String.Format("cmd /c %AZ_BATCH_APP_PACKAGE_TEST1#1.0%\\ImageTest\\TaskApplication.exe");
The inside implementation is fairly neat as well.
Please note the reason:
%AZ_BATCH_APP_PACKAGE_TEST1#1.0%\\ImageTest\\TaskApplication.exe"
Is because my application package zip contains the TaskApplciaiton.exe under the following structure:
==> ==>
To add further: An application package is a .zip file that contains the application binaries and supporting files that are required for your tasks to run the application. Each application package represents a specific version of the application.+
You can specify application packages at the pool and task levels. You can specify one or more of these packages and (optionally) a version when you create a pool or task.+
• Pool application packages are deployed to every node in the pool. Applications are deployed when a node joins a pool, and when it is rebooted or reimaged.
Pool application packages are appropriate when all nodes in a pool execute a job's tasks. You can specify one or more application packages when you create a pool, and you can add or update an existing pool's packages. If you update an existing pool's application packages, you must restart its nodes to install the new package.
• Task application packages are deployed only to a compute node scheduled to run a task, just before running the task's command line. If the specified application package and version is already on the node, it is not redeployed and the existing package is used.
Task application packages are useful in shared-pool environments, where different jobs are run on one pool, and the pool is not deleted when a job is completed. If your job has fewer tasks than nodes in the pool, task application packages can minimize data transfer since your application is deployed only to the nodes that run tasks.
The sample attached contains both pool level level as well the task level demo.
Steps:
At first add a new Application Package into my batch account: you can do that via portal. (the git project has test1.zip along with this git sample console app.
Then open your DotNetTurorial solution:
Fill in these info for the batch account credentials or any storage account in use for your credentials correctly:
Hit start the barebone.cs is set as the start project, ** please note you might need to change your *.proj file, because in my local all nugets were getting sourced from c:\cxcache
Please also note, there will be prompt to delete the job and pool, if you want to checkout the return result of this app, please keep the job and pool and then go inside node inside that pool and checkout stdout.txt file for the txt printed. (Note: you probably want to delete job and pool from the portal once you are done.)
The screenshots from my successful run are below:
So I was able to see the Test Success getting printed in my stdout.txt inside node from the TaskApplication.exe which was part of this application package.
The code used in this sample barebone app is reused fomr the sample existing here:
https://github.com/Azure/azure-batch-samples/tree/master/CSharp/ArticleProjects/DotNetTutorial.
Other friendly screenshots:
Jenkins official Wiki page for Matrix projects isn't really helping me; so I have a few questions.
We're trying to build a couple of projects that are all essentially the same, just some are being branded differently for our customers. In other words, the software / tests / etc. are all identical, except for some tweaks to turn BrandA into BrandB (or BrandC, etc.)
I figure I should be using a Matrix project to create builds for BrandA, BrandB, etc. While I haven't figured out all my steps yet (including how to rename executables after they're built) I know that I will need to pass the Brand Name to many of my Jenkins Powershell scripts during the build process, and then use that brand n the script.
How do I get these variables into my scripts? Are they automatically passed in to every build step in Jenkins? What is the variable name to use?
Finally, is there a good resource on building these multi-configuration projects in Jenkins? I can't seem to find anything comprehensive online.
If you usually build the job for BrandA and only occasionally for BrandB and BrandC a matrix project may not be what you want. I recommend, instead, using a parameterized job where the brand is a parameter whose default value is BrandA. If the parameter is named BRAND the parameter is accessible in all of the builds and publish steps with ${BRAND} and as an environment variable as %BRAND%.
I refer you to the parameterized build wiki for more details.
Yes, ${BRAND} and %BRAND% should work fine.
If you're using Maven, ${env.BRAND} does this too.
There's a plugin that you can see all Environment Variables that are available to your job/build.
https://wiki.jenkins-ci.org/display/JENKINS/EnvInject+Plugin
I'm not aware of that kind of process but I suggest you tu use the Copy project functionnality.
New Job
Copy From existing job
You will have a copy of your Job and you'll be able to setup easily all specific fields.