I am trying to create my jobs through JJB and almost all parameters are present.
But I can't find the parameters for the repositories that are in the Additional Behaviours category.
Tell me how to configure them using JJB?
Maybe you need additional plugins?Options screen
The list of options in the web UI are for the git plugin. You can find them in JJB under the git scm module. If you wanted to add Prune stale remote-tracking branches (git remote prune origin`) you would use:
- job:
name: git-prune-remote
scm:
- git:
prune: true
Full online documentation: https://jenkins-job-builder.readthedocs.io/en/latest/scm.html#scm.git
Related
We've been using Bamboo YAML specs to run our build plans. We use the default repository + a linked repository in that plan. The build plan now triggers if a commit/new branch has been created in the default repository (=desired behavior), but also when the linked repository has an update (=undesired behavior). How can I disable this via YAML specs?
The Bamboo documentation does not help me, and looking at a 'normal' (non-YAML specs) build plan does not work either, since this option is not converted to YAML specs when selecting 'view as YAML specs'. It does not show in the YAML specs if the trigger of the linked repo is on or off (see attached picture).
Help would be much appreciated!
Insert a script task that compares bamboo.planRepository.<position>.revision to bamboo.planRepository.<position>.previousRevision (find the correct <position> for your repository). Skip the plan build (exit 0) if the two are the same.
Move away from YAML specs. They are still very limited compared to Java specs.
This will disable trigger
---
version: 2
triggers: []
https://docs.atlassian.com/bamboo-specs-docs/8.2.0/specs.html?yaml#plan-branches
This will enable trigger for specific repository
---
version: 2
...
triggers:
- bitbucket-server-trigger:
repositories:
- your_repository_name_here
https://docs.atlassian.com/bamboo-specs-docs/8.2.0/specs.html?yaml#triggering-selected-repositories
Getting the following error when using drone cli to add/activate repo
No help topic for 'add'
I can confirm I am successfully login and I am an admin.
{"id":1,"login":"XXXXX","email":"","machine":false,"admin":true,"active":true,"avatar":"https://bitbucket.org/account/XXXX/avatar/32/","syncing":false,"synced":1578888217,"created":1578431775,"updated":1578891320,"last_login":1578891344}
I can also list my repo using 'drone repo ls'
My guess, if you are using the add option is that you are still interacting with drone 0.8 or below, in this case the docs have been archived to an alternate location in favor of the latest version (v1.x). The old docs are still available under the following URL and help for the add option is present there:
https://0-8-0.docs.drone.io/cli-repository-add/
If you are not using 0.8 and are indeed trying to use 1.x, perhaps you are referencing improper documentation, as this cli option shifted in v1 to enable
$ drone repo enable <repo/name>
Regardless of the versions however, you will want to ensure you both have admin access to the repository (so that drone is able to add the appropriate webhooks) and also refresh or sync your repo listing in if it is something brand new:
$ drone repo sync
username/hello-world
organization/minio
...
NOTE: This might take a bit depending on how many repos you have access to
I'm using Gitlab CI on one of my projects and I face the following problem :
My master build fails since a lot of time...
I push a new branch built from the master (no new commits) and push it, the build works.
I think that it's related to build cache because the codebase is strictly the same... The latest valid build cache may make the current code base failed...
Is there a way to clean the build cache on a specific branch ? In my case the master ? From the API ?
Finally, the Gitlab Team gave me the solution on Twitter : https://twitter.com/gitlab/status/832674380790394880
Since my repository is hosted on gitlab.com, I can't remove the cache by myself. But on the .gitlab-ci.yml file documentation, it's explained that we can use a cache:key entry.
This cache:key is used to determine how the cache entry is named so I can change the default value to start on a blank cache 😊.
Below a sample of my .gitlab-ci.yml file :
my-asset-build:
cache:
key: "$CI_COMMIT_REF_NAME-assets"
With that configuration, my cache is related to the current ref (so a build on the same ref will use the cache) with a suffix !
Thanks to the Gitlab Team for their quick answer on Twitter !
If you have trouble with the variable name, maybe you need to check this page : https://docs.gitlab.com/ce/ci/variables/README.html#9-0-renaming
Also, since Gitlab 10.4, we have a "Clear runner cache" button in the pipeline list. Clicking on that button will have the same effect than changing variable name without polluting commit history.
The Clusters-tab in the Spinnaker web UI shows my Server Groups and their deployment version (V000 ... Vn). Next to the deployment version, some build information is displayed, which in my Spinnaker instance is always (No build info).
Is there a way to add some build info, for example a Git commit/tag or Docker tag?
Right now the build info is based on the jenkins build information. It derives this information from the ami tags appversion and build_host to link back to jenkins. appversion has to follow a defined schema, see this comment in the Rosco source code for example.
You cannot customize these values at this point, but a pull request is welcome
I'm trying to tag the git repo of a ruby gem in a Bamboo build. I thought doing something like this in ruby would do the job
`git tag v#{current_version}`
`git push --tags`
But the problem is that the repo does not have the origin. somehow Bamboo is getting rid of the origin
Any clue?
Yes, if you navigate to the job workspace, you will find that Bamboo does not do a straightforward git clone "under the hood", and the the remote is set to an internal file path.
Fortunately, Bamboo does store the original repository URL as ${bamboo.repository.git.repositoryUrl}, so all you need to do is set a remote pointing back at the original and push to there. This is what I've been using with both basic Git repositories and Stash, creating a tag based on the build number.
git tag -f -a ${bamboo.buildNumber} -m "${bamboo.planName} build number ${bamboo.buildNumber} passed automated acceptance testing." ${bamboo.planRepository.revision}
git remote add central ${bamboo.planRepository.repositoryUrl}
git push central ${bamboo.buildNumber}
git ls-remote --exit-code --tags central ${bamboo.buildNumber}
The final line is simply to cause the task to fail if the newly created tag cannot be read back.
EDIT: Do not be tempted to use the variable ${bamboo.repository.git.repositoryUrl}, as this will not necessarily point to the repo checked out in your job.
Also bear in mind that if you're checking out from multiple sources, ${bamboo.planRepository.repositoryUrl} points to the first repo in your "Source Code Checkout" task. The more specific URLs are referenced via:
${bamboo.planRepository.1.repositoryUrl}
${bamboo.planRepository.2.repositoryUrl}
...
and so on.
I know this is an old thread, however, I thought of adding this info.
From Bamboo version 6.7 onwards, it has the Git repository tagging feature Repository Tag.
You can add a repository tagging task to the job and the Bamboo variable as tag name.
You must have Bamboo-Bitbucket integrated via the application link.
It seems that after a checkout by the bamboo agent, the remote repository url for origin is set as file://nothing
[remote "origin"]
url = file://nothing
fetch = +refs/heads/*:refs/remotes/origin/*
That's why we can either update the url using git remote set-url or in my case I just created a new alias so it does not break the existing behavior. There must be a good reason why it is set this way.
[remote "build-origin"]
url = <remote url>
fetch = +refs/heads/*:refs/remotes/build-origin/*
I also noticed that using ${bamboo.planRepository.<position>.repositoryUrl} did not work for me since it was defined in my plan as https. Switching to ssh worked.