I have two projects, both of the have the same jobs (becuase they "extends" the same .guint job which has os_stop action)
The first project runs automatically manual job with action on_stop after merge, but the second project does not do this. Are there any specific settings for this action or what I missed?
Gitlab version 13.15
I was searching for info, but nothing found on this problem
Related
We developed a CI system that runs via Github actions on self-hosted runners.
In order to prevent building unnecessarily, we incorporated a pre-build job that triggers a build only if the commit message has [trigger ci] anywhere.
Now we are facing a slight annoyance: Even if the build job doesn't run, we still have a workflow run show up in the workflow runs list, as expected, but it has basically become a copy of the commit history and very hard to navigate or find which workflows did actually build.
Is there any way that I can delete a workflow run from the workflow runs list conditionally, within the workflow itself? This way, we can keep only the runs that did trigger a build, and delete the ones that skipped building.
I want to trigger a build in Teamcity by doing a manual action(not a commit or pullrequests). Like if i click a button in github it should trigger a build config in teamcity or something similar(by passing the branch). I dont want the process to be automatic for every commits, instead just manually trigger for custom branches.
If there is a possibility for this, pls let me know as it would be much helpfull..
Thanks in advance!
Yes you can do that by leaving your Triggers menu empty...
Go to Build --> Edit settings --> Triggers and make shore that there are no triggers. You can alway manually run build by clicking on icon RUN
If you want trigger just for couple of branches you can add trigger to your VCS like this
so my list contains branches develop, qa, release and master and rule +:*/merge is for every open Pull Request
So, I've been using Jenkins for quite a while. I have set up numerous projects with the Github Pull Request Builder plugin to run tests whenever someone opens a pull request, and then trigger some other job (build, push, deploy, etc) whenever the pull request actually gets merged to master.
So, is there any way to set this up with a Jenkinsfile, or the organization folders, or the multibranch build deal?
The github-organization-folder plugin in combination with the multi-branch plugin plugin offers exactly this awesome feature: It scans a whole organization (optionally restricted to certain patterns in repo/branch names) for Jenkinsfiles and automatically adds jobs. This also happens for Pull Requests.
Once the PR is closed, it automatically removes the job.
To avoid arbitrary code execution, an organization member has to trigger building the job (same as for the GPRB plugin). The phrase can be configured in the Jenkins System settings.
EDIT: Under the Advanced section in Jenkins, you find options about what types of PR you want to build. If you build fork PRs, then there's afaik no way to prevent running code without prior inspecting it.
An example, how this looks like:
In my Teamcity build configuration I have three VCS configured:
If any of those would have a check-in - the trigger would fire and my build would be running.
What I need to know - which from those repositories had fired the trigger.
What I can know is the type of the trigger event: echo %teamcity.build.triggeredBy% (in case if the build was triggered automatically it would say "GIT") , however, I don't' see any option to know which VCS had triggered the build.
Any thoughts how this could be achieved?
I have a Jenkins Workflow which I am able to run by clicking Build. But when I try to start it from the Build other projects post-build action of an (freestyle) project, I just get an error in the form
my-flow is not buildable
and the downstream flow is not run when the upstream project is built.
The post-build action Build other projects does not simply do what it sounds like: build those projects when the step is run. In fact running the step does nothing at all. Instead, it causes the named projects to be included in an edge of the dependency graph, and downstream projects according to the graph are then run according to separate logic. And currently the dependency graph API is defined in such a way that Workflow jobs cannot participate. Long story short, that mode does not work.
The Parameterized Trigger plugin offers other ways to start downstream jobs. The nonblocking trigger works much like the Jenkins core trigger: it affects the dependency graph. There is also a blocking trigger (which is a build step, not a post-build action), which just does what you probably expected: start the downstream build (much like the build step in Workflow). Currently this plugin does not support Workflow, though it would probably be easy to make it use more current APIs so that it would: JENKINS-26050
What does work is to configure the relationship in the reverse direction: in the Workflow job configuration, select Build after other projects are built and select your freestyle project. Now when the freestyle project finishes building, the Workflow job is triggered.