So I'm doing a build with drone.io and I'm wondering if with the build/deploy/publish steps it is possible to do:
when:
tag: PRODUCTION
Or something similar in the same way it is possible to do with branches.
If not is there anyway to use the $$DRONE_TAG variable to do this for you or is it necessary to manipulate the git hook somehow?
You can filter steps based on the hook event type:
when:
event: tag
If you need to filter steps based on the tag name, this may be possible depending on which version control hosting provider you are using. If you are using GitHub, when drone processes a tag hook event, it sets the branch to refs/tags/%s. This means you can filter tags based on branch name:
when:
event: tag
branch: refs/tags/PRODUCTION
Related
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.
I'm doing a script that sends a message in Ryver based on certain events for GitLabs Merge Request. The supported scenarios:
When a Merge Request is created
When comments are made (Code Review)
when new commits make the pipeline fail
The following allows to limit the pipeline to merge requests only:
only:
- merge_requests
script:
- ./ryver.sh #This does the logic of sending the message based on the events
I tried using export to print all the variables in the pipeline but couldn't find a way to explicitly detect the event that triggered this job (Code Review, Creation, etc).
I tried:
Merge Request status
Comparing commits
Using times (not very reliable way)
I wonder:
Can we detect what event triggered the pipeline within the Merge Request scope?
Or
Do I need to use a WebHook to access this information?
Or
There is another way to do what my team is trying to do?
I'm open to suggestions or other ways to do it that are not related to the gitlab-ci.yml, as long as it is free
Can we detect what event triggered the pipeline within the Merge Request scope?
Yes, this is contained in the predefined CI_PIPELINE_SOURCE variable, as frakman1 answered.
Do I need to use a WebHook to access this information?
It depends what you want to do. as stated above, this information is available inherently in the pipeline as a predefined variable.However, it should be noted that only certain events trigger merge request pipelines at all.
For example, comments on merge requests do not trigger pipelines. If you want to react to comments or status changes, you will probably need a webhook.
The pipeline source information is available both in webhooks and the list pipelines API in the source key of the response (in GitLab 14.3+).
Webhooks expose the event in the X-Gitlab-Event header and payload for the relevant events.
There is another way to do what my team is trying to do?
Webhooks will likely be more reliable than relying on in-pipeline jobs because webhooks can capture more events than jobs/pipelines can. Webhooks, for example, could send you notifications even when no pipeline is created at all. It will also work if your pipeline is blocked/timed out for some reason.
The disadvantage, however, is that you will need to develop and host your own web application to handle the incoming webhooks.
There are many project integrations built into GitLab for sending notification webhooks directly to various services. Unfortunately, Ryver is not one of them.
If you want to send notifications from jobs, I have found using apprise simplifies this greatly and supports ryver.
A basic template job may look like this:
.send_notification:
image: python:3.9-slim
before_script:
- pip install apprise
variables:
RYVER_ORG: "YourOrganization"
# Define RIVER_TOKEN in your CI/CD variables settings
NOTIFICATION_TITLE: "Placeholder Title"
NOTIFICATION_BODY: "Placehodler Body"
script:
- apprise -vv -t "${NOTIFICATION_TITLE}" -b "${NOTIFICATION_BODY}" "ryver:///${RYVER_ORG}/${RYVER_TOKEN}"
Using jobs in combination with when: on_failure or when: on_success can be useful:
stages:
- build
- build_notification
build:
stage: build
script:
- make build
notify_build_failure:
stage: build_notification
when: on_failure
extends: .send_notification
variables:
NOTIFICATION_TITLE: "Failed - $CI_PROJECT_NAME pipeline $CI_PIPELINE_ID"
NOTIFICATION_BODY: "The build failed for the pipeline. See $CI_PIPELINE_URL"
notify_build_success:
stage: build_notification
when: on_success # the default
extends: .send_notification
variables:
NOTIFICATION_TITLE: "Build Success - $CI_PROJECT_NAME pipeline $CI_PIPELINE_ID"
NOTIFICATION_BODY: "The build has succeeded. See $CI_PIPELINE_URL"
Or using a default after_script which will run even if the job fails. This is an easy way to have your ryver.sh script evaluated after each job. The script logic can determine whether to send the notification and the contents of the notification.
default:
after_script:
- ./ryver.sh
You can use logic like this to detect that the commit came from a Merge Request:
$CI_PIPELINE_SOURCE == 'merge_request_event'
See here for more details on how to control what kicks off a pipeline.
You can find out what triggered a pipeline by looking at this variable:
CI_PIPELINE_SOURCE
From docs:
See here for more details about pre-defined variables.
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.
We are starting to use Bamboo to monitor our builds, and we have started to use the "branches" facility from the build plans. These work great, except for one thing, on the wallboard, only the "main" build status is shown, not the status of the branches. Given that our branches are also release branches, we would like to see the status of the main branch and all of the "release" branches, but not the "hot fix", "feature", or "bug fix" branches.
Is this possible?
Try using a label:
https://confluence.atlassian.com/bamboo/displaying-the-wallboard-289276971.html
Also there is this:
https://confluence.atlassian.com/bamboo/using-plan-branches-289276872.html#Usingplanbranches-wallboard
But it looks like the wallboard is a bit of an unloved feature - they have some feature requests still open for it with a lot of watchers/votes that haven't been touched in three years or more.
You could also probably just implement your own wallboard and use the REST API to get statuses - the UI for wallboards is not very complex, and having your own javascript code accessing the REST API would give you complete control.
I'm making good progress on creating a generic javascript to build a task list/tree that ultimately be run on a wiki. The challenge is that I would like to have multiple instances of this script running pointing the various subprojects that are layered under different projects in a workspace. Is there a way to pass the context parameters (Parent Project,Project, Iteration, Release etc.) via the Rally.launchapp/bootstrap? That way there is a quick common spot to tune this via the wiki markup. Thanks! Mark
Rally.launchApp('CustomApp', {
name: "RallyGrid",
parentRepos: " "
});
});enter code here