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
Related
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 am trying to use a global Jenkins variable in the Repository URL field:
Repository URL: ${BUILD-PEND-SRC}
BUILD-PEND-SRC is defined in Configure System and a value of a proper URL is set. If I do a shell execution job with echo ${BUILD-PEND-SRC} it does display the correct value.
However, when I run the job, I get
ERROR: Failed to check out ${BUILD-PEND-SRC}
org.tmatesoft.svn.core.SVNException: svn: E125002: Malformed URL '${BUILD-PEND-SRC}'
Which tells me that Jenkins did not resolve ${BUILD-PEND-SRC}.
I am summarizing the SO answer that solved it for git-based Jenkins pipeline jobs but also applies to svn-based jobs: https://stackoverflow.com/a/57065165/1994888 (credits go to #rupesh).
Summary
Edit your job config
go to the Pipeline section
go to the definition Pipeline script from SCM
uncheck Lightweight checkout
The issue seems to be with the scm-api-plugin (see the bug report in the Jenkins issue tracker), hence, it is not specific to a version control system.
In TFS, i'm doing build for my .Net project. I've got agent configured locally and build is carried using that. Error says as follows
Cannot listen on pipe name 'net.pipe://localhost/taskagent/6/xxxxxx' because another pipe endpoint is already listening on that name.
Not sure, what this exactly is....Please help. Attached the error screenshot for reference.
Note: I'm not using any TDD/test process in code
According to the error info not sure if it's related to TFS side. Suggest you also manually run the build directly on the build agent.
Since the agent is newly configured, to narrow down if the error is related to your environment on the build server machine. You could also create a new build definition with a simple project such as hello world and check if got the same error. If so, suggest you delete the agent, reconfigure it follow this tutorial: Deploy an agent on Windows
Besides, you could also set system.debug=true to enable verbose debug for build to get more detail error info, please refer: Enable Verbose Debug Mode for TFS Build vNext
I want to download the latest log of a Bamboo job programmatically to parse its content and display in a dashboard.
However, Bamboo does not provide a direct link (e.g. with "latest" in URL similar to artifacts download) or to make the Bamboo build log as an artifact.
Someone who has worked around this issue, please share the knowledge.
Check out the REST API offered for bamboo builds: https://docs.atlassian.com/bamboo/REST/6.0.0/
Here's one example from Atlassian's community: https://community.atlassian.com/t5/Answers-Developer-Questions/How-do-you-get-the-build-log-using-REST-API/qaq-p/485212
See "expand": https://docs.atlassian.com/bamboo/REST/6.0.0/#d2e485
... expands build result details on request. Possible values are: changes, metadata, artifacts, comments, labels, jiraIssues, stages, logEntries. stages expand is available only for top level plans. It allows to drill down to job results using stages.stage.results.result. logEntries and testResults are available only for job results
At least as of Bamboo 6.7.1 (and possibly earlier versions), you can issue a request directly for the log using a Script Task, curl, and Bamboo variables:
curl -X GET --user username:password \
"http://localhost:8085/download/${bamboo.buildKey}/build_logs/${bamboo.buildResultKey}.log"
That will give you the textual output of the log.
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.