I know that there is something like context.pipelineRun.name but that's only available in the pipeline. How can I get the pipeline name inside a task to build a link to the Tekton-dashboard, WITHOUT a parameter?
As what I know
context.pipelineRun.name
should work in your Task, if your Task is executed in a PipelineRun - since Tasks is the way to execute things in a Pipeline. Although, this variable will not be available if you run your Task standalone.
From Tekton's documentation (https://tekton.dev/docs/pipelines/variables/) the name of the pipelinerun is not available in the task.
So, I see only the possibility to pass it as a parameter from the pipelinerun (where it is available under context.pipelineRun.name). Or you use the task's name (context.taskRun.name), if that is sufficient for you.
Related
we are using Spinnaker to automate our deployment pipelines. As part of the pipelines we have some custom stage that generate change tickets in JIRA for the release (some mandate we have from a regulatory perspective). The custom stage then waits for the change ticket to be approved and moves on. This all works perfectly.
What we are now trying is to add another stage at the end of the pipeline that moves the change ticket to done. For this, we would somehow need to be able to catch the JIRA ticket reference in the previous custom stage and pass it to this custom stage which can then move the JIRA ticket to done using the ticket reference that was passed to it.
Did anyone try passing data from one custom stage to another before?
Looking forward to your responses,
Moritz
Add a new parameter in your configuration stage:
Now assign the Jira ticket number from your Create ticket stage to this variable. The value can be accessed based on how you call the JIRA api and how you get the output. The output can be accessed by spinnaker expressions, for example I am accessing the output for a stage (type: Find Image name from prod cluster stage) like this ${#stage("stagename")["outputs"]["artifacts"][0]["version"]}. This expression cannot be reused and will be unique to your call and how you get the output. So change the expression accordingly. ${parameters.jiraTicket} = ${#stage("stagename")["outputs"]["artifacts"][0]["version"]}
In your 3rd stage you can now use the spinnaker expression ${parameters.jiraTicket} and then close the jira ticket.
You can ignore the steps 1 and 2 and directly use the spinnaker expression from step 2 in step 3 as well.
I am trying to invoke a state machine from an s3 event. Everything is perfect and working fine. However, I am looking to name the State Machine execution name with a custom name. Example: s3 object key so that it is easy to refer to the state machine execution
The above Name I would like to rename with the S3 Object name with which the State machine invocation is triggered.
Any help is appriciated.
Use a Lambda function in between, and call StartExecution with any execution name you want.
Also consider this side effects:
You need to pay additional cost for Lambda invocation.
for keeping X-Ray, you need to handle it inside your Lambda code and even also the additional Lambda invocation will be visible in X-ray trace view.
Lambda could become a bottleneck if have many s3 events.
I need to create a Bamboo task that task needs to invoke my project Rest API(http://host:port/api/......) to perform the business logic. Is it any way is there to achieve this? Where i need to mention my API URL and how it will pick my code?
You can use Script task to invoke curl command as part of job. Project REST endpoint can be plan variable, if it doesn't change often.
This doesn't seem like a situation that is unique to me, but I haven't been able to find an answer anywhere.
I am attempting to build Jmeter scripts that can be executed both in the GUI and command line. The command line is going to need values to pass into the test cases, but the same test cases need to be executed via the GUI as well. I initially had separate scripts for GUI and command line, but it seemed redundant to have the same test cases duplicated with just a couple parameters changed.
For example, the GUI test case has the Web Server name set to:
<!-- ${ENV} set in User Defined Variables -->
<stringProp name="HTTPSampler.domain">${ENV}</stringProp>
The command line test case uses the following for parameters:
<!-- Define via command line w/ -JCMDDEV -->
<stringProp name="HTTPSampler.domain">${__P(CMDENV)}</stringProp>
Both work for their served purpose, but I want to combine the tests to be easier maintained and to have the ability to run them via GUI or command line.
I got passed one hurdle, which was combining the GUI Variables to be used as well as Properties for the command line by setting the User Defined Variable ${ENV} as the following:
Name Value
----- --------
ENV ${__P(ENV,dev.address.com)}
I am now able to run the same test case via GUI and command line (defining a new environment with -JENV)
I'm not sure if I'm overthinking this, but I want to be able to add a variable to the property default in order to avoid typos, etc while handing it off to others. I tried a few variations that didn't seem to work:
Name Value
----- --------
ENV ${__P(ENV,${__V(DEV)})}
DEV dev.address.com
This gave me the following Request:
POST http://DEV/servlet
Instead of:
POST http://dev.address.com/servlet
I also tried using:
${__P(ENV,${DEV})}
${__property(ENV,,${__V(DEV)})}
${__property(ENV,,${DEV})}
I was looking into Jmeter nested variables, but it didn't provide any working solutions.
So to my main question, am I able to use variables as the property defaults. If so, how would I achieve that?
I found a way around this. It's not exactly how I wanted it, but it could work for right now.
I really wanted to keep everything in one place where people had to make edits, but I was able to get the User Defined Variables to work by adding the ${__P(ENV,${DEV})} to the HTTP Request Defaults Web Server Name instead of pre-defining it as a variable.
Now there are two Config Elements that potentially need to be edited with GUI execution, but I think it should work out better in the long run.
Yes, seems the author is right - looks like nested variable can't be evaluated in JMeter from the same variables scope.
I've created a different "User Defined Variables" set, added there "defaultValue" - and after that this option works:
${__P(myProperty, ${defaultValue})}
I was wondering if there was a way to do this in Hudson (or with any of the various plugins). My IDEAL scenario:
I want to trigger a build based on a job through a REST-like API, and on that build, I want it to return me a job ID. After-wards, I would like to poll this ID to see its status. When it is done, I would like to see the status, and the build number.
Now, since I can't seem to get that working, here is my current solution that I have yet to implement:
When you do a REST call to do a build, its not very REST-ful. It simply returns HTML, and I would have to do a kind of parsing to get the job ID. Alternatively, I can do a REST call for all the history listing all the jobs, and the latest one would be the one I just built. Once I have that, I can poll the console output for the output of the build.
Anyone know a way I can implement my "ideal" solution?
Yes, you can use the Hudson Remote API for this (as #Dan mentioned). Specifically, you need to configure your job to accept Remote Triggers (Job Configuration -> Build Triggers -> Trigger builds remotely) and then you can fire off a build with a simple HTTP GET to the right url.
(You may need to jump through a couple additional hoops if your Hudson requires authentication.)
I'm able to start a Hudson job with wget:
wget --auth-no-challenge --http-user=test --http-password=test "http://localhost:8080/job/My job/build?TOKEN=test"
This returns a bunch of HTML with a build number #20 that you could parse. The build number can then be used to query whether the job is done / successful.
You can examine the Hudson Remote API right from your browser for most of the Hudson web pages that you normally access by appending /api (or /api/xml to see the actual XML output), e.g. http://your-hudson/job/My job/api/.
Update: I see from your question that you probably know much of what I wrote. It is worth exploring the built-in Hudson API documentation a bit. I just discovered this tidbit that might help.
You can get the build number of the latest build (as plain text) from the URL: http://your-hudson/job/My job/lastBuild/buildNumber
Once you have the build number, I think the polling and job status is straightforward once you understand the API.
And what if you don't want the latest build number, but you want the build number of the build that was triggered by hitting the build URL ?
As far as I can tell, hitting that URL returns a 302 that redirects you to the job's mainpage, with no indication whatsoever of what the build number is of the one that you triggered.