I've enabled the option - Settings/General/Merge Requests/Merge Checks - Pipelines must succeed.
Since then every merge requests automatically starts execution of the pipeline which is actually what i want. The problem is that this is running forever , i'm receiving message : Checking pipeline status
If i run the pipeline manually from CI/CD Pipelines - Run pipeline finish immediately. I don't understand what is wrong and why it stuck , can i check logs somewhere or something ?
For testing , the pipeline is really simple , just exit 1 .. but still not working ..
At this stage , "running pipeline" is not listed in pipeline list even if the status in merge request is
Checking pipeline status
We ran into a case where a merge request does not contain the .gitlab-ci.yml file. The fix is simply to do a rebase
For troubleshooting purposes, pipelines can be run manually on particular branches at CI/CD -> Pipelines -> Run Pipeline
For me what happened that .gitlab-ci.yml file was having issue as I have mentioned "master" as value for "only" label .. , then everything worked after updating it with my correct branch name which IMO should be "main"
Encountered this myself just now, using Gitlab shared runners. Tried re-running one individual job from the pipeline in the hope that it would resolve the issue. It did not. The best way is to change the commit id of the latest change in the MR.
You can either create an empty commit as suggested by #Bhargav11 or, to keep a cleaner commit history, do
$ git commit --amend --no-edit
$ git push --force
on your branch.
check if current branch you are checking the pipeline status and branch specified in "only: field" are same
only:
- master
This happens to me with pipelines that has no job that triggers on merge-requests.
If I have no tests or anything I wish to run during a merge requests I create a "dummy" job that doesn't do anything.
Rule to trigger on merge requests:
rules:
- if: $CI_PIPELINE_SOURCE == 'merge_request_event'
Then add a simple echo in the script section:
script: echo "Dummy job for merge-request"
Just add an empty commit to trigger it again.
git commit -n -m "commit comment"
From GitLab documentation:
"Checking pipeline status" message
This message is shown when the merge request has no pipeline
associated with the latest commit yet. This might be because:
GitLab hasn't finished creating the pipeline yet
You are using an external CI service and GitLab hasn't heard back from the service yet.
You are not using CI/CD pipelines in your project.
You are using CI/CD pipelines in your project, but your configuration prevented a pipeline from running on the source branch for your merge request.
The latest pipeline was deleted (this is a known issue).
I found what was wrong in my case. The problem was with the runners. There was "Shared runners" enabled by default which caused the confusion. I've just disabled them and enable my own runner and everything started to work as expected. You can check this in CI / CD Settings, I think they are enabled by default. Basically , pipelines are nothing more than a trigger for the runner... then the runner is responsible for the execution.
In our case, simply creating a copy of the branch (git checkout -b new-branch-name) and making a new MR with the identical code allowed us to work around the issue. The new MR pipeline executed successfully.
In my case, I had made a typo on the filename and had forgotten to add a dot before it.
Please ensure the filename is .gitlab-ci.yml
How did I debug this?
On the GitLab UI, I went into CI/CD editor and couldn't see my file.
Related
I am planning to experiment building a pipeline using Azure DevOps. One thing that I noticed early on is, after azure-pipelines.yml created, I have to commit this first before being able to run it. But I want to experiment on it which revolves around trial and error. Doing multiple commit just to test things out are not feasible.
In Jenkins I can just define my steps and try to run it without committing the file.
Is this also possible to do in Azure DevOps?
But I want to experiment on it which revolves around trial and error. Doing multiple commit just to test things out are not feasible.
Yes it is - you just use a different code branch. That will allow you the freedom to make as many changes as you need, while putting the pipeline together and trying it out, without committing to the master branch.
Then when you're happy with the way the pipeline is running, you can merge your branch into the master branch which the pipeline normally uses.
You cannot run YAML pipelines without committing them, but you can create classic pipelines and run them without committing anything pipeline-related to the repository (except for the source code you want to build). Classic pipelines can later be turned (or copy-pasted, to be exact) into yaml pipelines with view YAML -option.
https://learn.microsoft.com/en-us/azure/devops/pipelines/get-started/pipelines-get-started?view=azure-devops#define-pipelines-using-the-classic-interface
If you're on your own branch, or in a repository without any other developers making changes then you can
Make a change
use git commit --amend to overwrite your previous commit with the new file
use git push --force-with-lease to push that up to Azure DevOps
That will hide your commit history while experimenting
I have created a pipeline in my repository which is used to validate code by executing unit tests for code that is being pushed to features/* branches. The same pipeline is used as Build validation pipeline set as Branch Policy on the develop branch to validate incoming PRs. This is the trigger of the pipeline.
# pipeline.yml
trigger:
batch: false
branches:
include:
- features/*
However we have come across the following condition: Given an open PR from refs/heads/features/azure-pipelines -> refs/heads/develop we push a commit on the features/azure-pipelines branch.
This causes the pipeline to trigger twice. To my understanding one of the runs is due to the trigger of the pipeline (The one marked as Individual CI on the screenshot) and the second run is due to branch policy trying to validate code being pushed onto the open PR to develop. (The PR Automated)
Is there any way to disable one of the executions since it's essentially a duplicate? I was maybe looking for a way to retrieve open PRs and abort execution of a pipeline for Individual CI if there is an open PR for a branch but I am not sure that's the best way around that and I am looking for options.
You can set
trigger: none
This way only the branch policy will trigger the pipeline.
Is there any way to disable one of the executions since it's essentially a duplicate?
As we know, we could not disable the Build validation pipeline set as Branch Policy on the develop branch to validate incoming PRs unless we cancel the Build validation.
For your situation, you could try to include [skip ci] in the commit message or description of the HEAD commit to make the Azure Pipelines skip running CI when you plan to merge the features branch to the develop branch.
You could check the document Skipping CI for individual commits for some more details.
Here it depends if they does the same. You can have conditional checks in the pipeline which does a different things for PR and CI runs. However, I'm pretty sure that this is not possible, because one is defined on the YAML and the second on the Azure DevOps portal. So even if you disnle PR trigger here in YAML, a branch policy still runs a PR. And you can specify antyhing in YAML to block branch policy.
I am working with files inside a GitLab CI/CD pipeline and push them in the repository at the end of the job.
The problem is that the push itself trigger the run of the pipeline.
I tried to solve this issue by adding the keyword [ci skip] in the commit message.
It is working but still add a pipeline skipped in the history:
Is there another way to skip the pipeline after a push in a pipeline run without seeing this skipped pipeline?
Unfortunately this skipped pipeline can not be hidden, the only solution is to run use workflow only when pipeline is triggered manually or from pipeline, but it will block any commit to create pipeline.
There is an open change for this: gitlab#28369
I want to trigger a build before pull request starts for merging (in Azure DevOps). For this option, I have added the Build validation under branch policies. But if I created a new Pull Request, I am getting the message as "Unable to queue build".
Please anyone let me know the option I selected solves my requirement. If yes, how to solve this "Unable to queue build" issue. If no, any option available to achieve my requirement.
Thanks
Your options is achievable, and the problem now is most likely caused by you triggering the pipeline in the wrong repository.
For example, if you create a pipeline from repository 1 and trigger the pipeline in a pull request created from repository 2, the pipeline will not be queued.
Modify your pipeline or PR repository so that the pipeline and PR use the same repository, this should be resolved.
I had the same problem and i changed the branch policy to include the build pipeline:
https://learn.microsoft.com/en-us/azure/devops/repos/git/branch-policies?view=azure-devops&tabs=browser
Branch policy could be found from:
Repos -> Branches
Click on the 3 dots to the right of the branch that the PR is going to.
I was also facing the same problem, checking pipeline for being disabled or edited anyhow, but no differences.
But by checking the linked work items (tasks/pbis), I saw that one or more had not been completed. After changing the states everything worked fine.
I'd can't seem to find any documentation of manual staging in Gitlab CI in version 8.9. How do I do a manual stage such as "Deploy to Test"?
I'd like Gitlab CI to deploy a successful RPM to dev, and then once I've reviewed it, push to Test, and from there generate a release. Is this possible with Gitlab CI currently?
You can set tasks to be manual by using when: manual in the job (documentation).
So for example, if you want to want the deployment to happen at every push but give the option to manually tear down the infrastructure, this is how you would do it:
stages:
- deploy
- destroy
deploy:
stage: deploy
script:
- [STEPS TO DEPLOY]
destroy:
stage: destroy
script:
- [STEPS TO DESTROY]
when: manual
With the above config, if you go to the GitLab project > Pipelines, you should see a play button next to the last commit. When you click the play button you can see the destroy option.
Update: Manual actions were Introduced in GitLab 8.10. From the manual "Manual actions are a special type of job that are not executed automatically; they need to be explicitly started by a user. Manual actions can be started from pipeline, build, environment, and deployment views. You can execute the same manual action multiple times." An example usage of manual actions is deployment to production. The rest of this answer applies to Gitlab 8.9 and older only.
Historical Answer:
It does not appear as though manual deploy/release was available in Gitlab in 8.9.
One possibility is to have a protected branch which triggers a release. See info about protected branches here: http://doc.gitlab.com/ce/workflow/protected_branches.html
Essentially a protected branch would allow you to Create a branch (testdeploybranch) which only you would be allowed to merge code into. Whenever a commit to dev would pass the Gitlab CI tests and deploy jobs, as well as your manual review, you could merge that commit into the protected branch to trigger the release. For this branch you can then set up a special release job in Gitlab CI using the only option in the .gitlab-ci.yml job definition. Read more here: http://doc.gitlab.com/ci/yaml/README.html
So something like this:
release:
only: testdeploybranch
type: release
script: some command or script invocation to deploy to Test
This might not be exactly what you are after, but it does allow you to do manual releases from Gitlab. It does not provide an easy way to manually do the same release procedure manually for different servers. Perhaps someone else might be able to expand on this strategy.
Finally, we have Gitlab CI manual actions that were introduced in GitLab 8.10.