After few of repositories were removed from GitHub, and then synced repos on Travis CI, the number of repositories displayed next to the info has stayed the same. Although, the actual repositories are not visible on Travis CI anymore.
Why is that? Is there a way of removing previous repos from Travis CI also just because they were removed already from GitHub?
On your profile page, you can enable or disable repositories:
Related
We host a project's source code on Bitbucket, in multiple repositories, one for the backend, one from the frontend, and one for server configuration and deployment.
The deployment is done with a Bitbucket custom pipeline hosted in the latter repository (where "custom" means triggered manually or by a scheduler, not by pushing to branch). In the pipeline, we clone the other repositories (using an SSH key for authentication), build Docker images, push them to a Docker repository, and then trigger the deployment on the server.
This is all working well, except for how it's tracked in Bitbucket and Jira. In Bitbucket, in the pipelines overview, it shows the latest commit that was deployed by a pipeline run. However, since the pipeline is in the config repository, this will only show commits of the config repository. Since the config rarely changes, most of our commits are in the backend and frontend repositories, so this "latest commit" rarely represents the latest change that was deployed.
Similarly, and more annoyingly, when connecting Jira with Bitbucket, Jira only associates commits in the config repository with a deployment. All the interesting work done in the backend and frontend repositories isn't seen.
Is there away to tell Bitbucket that multiple repositories are involved in a pipeline deploy? I believe this is currently not possible, so this would have to be a feature request for Atlassian.
Does anybody know of a workaround? I was thinking, maybe having the backend and frontend repos as git submodules of the config repo might work? Git submodules scare me, so I don't want to try only to find out that Bitbucket/Jira would not see the commits/issues in the submodules anyway.
Another workaround could be to push a dummy commit with a commit message that summarizes all commits done in all repos. That commit would have to be already pushed to the config repo when the pipeline is started, so that would maybe have to be done in a separate pipeline: the first pipeline pushes the summary commit and then triggers the second pipeline for the actual deployment.
Put everything, all software components plus configuration and infrastructure, together in a monorepository.
So as to push such a big change in historically independent repositories, it is worth to use the --allow-unrelated-histories option for the git-merge command so as not to loose each git history.
Otherwise, yes, use git submodules in a parent repo and track submodules refs updates as meaningful commits. If that scares you, you should really not be splitting your code in multiple repos.
We're using Jenkins to orchestrate our builds from GitLab using a Multibranch Pipeline strategy. Recently, something changed somewhere, and now Jenkins is no longer ignoring projects archived in GitLab.
We're using the following stack (not all may be relevant to the problem at hand, and certainly not the complete list of plugins, which would take many pages, if there are other items that I can provide, happy to do so):
Jenkins: 2.263.3
Git Plugin 4.5.1
GitLab Enterprise Edition: 13.7.9-ee
GitLab API Plugin for Jenkins: 1.0.6
GitLab Plugin for Jenkins: 1.5.13
GitLab Branch Source Plugin for Jenkins: 1.5.3
We have our projects organized into groups (with no subgroups) in GitLab, and have used a strategy to archive them when they're no longer needed (instead of deleting them). In Jenkins, we have set up a GitLab Group as an "organization folder", which configures itself to autoscan the GitLab group, searching for projects that have a file named "Jenkinsfile" (configured via project recognizer).
I haven't been able to correlate any recent changes to the behavior I'm seeing, but am still searching. Does anyone have any ideas of where to look to fix this, or is this a known issue?
Thanks!
I am new to CI with travis and I am trying to learn it by following a course. I have created a public repository in dockerhub, and pushed the project to github with .travis.yml file. I have previously connected and authorised travis at github. The github project can be found here. The travis build gets triggered and it appears to be successful, but nothing is pushed to dockerhub.
You can see the build process here:
The travis build appears to be successful, but nothing is pushed to docker hub. On expanding the log I could see this message is being logged:
Must provide --username with --password-stdin
But, I have already set up the environment variables in travis as you can see below, so I don't get why I get this message?
I didn't realise that environment variables need to be set per project. Also I wasn't even getting the option for settings for that repository until I synced again github with travis. Once I done the syncing part one more time, the option appeared and I was able to set the variables for that repository. And then the build process went through and the image was pushed to dockerhub.
I have a Jenkins system. It runs build jobs for our company. We run multibranch pipelines. Yesterday one of the builds mysteriously dropped the devel branch from the build.
I looked through the Pull Requests for the branch and I can not find anything that affected by the Jenkins file in the time frame where this branch drop occurred.
I have looked through the Jenkins system log and I do not see any errors. Here is a copy of the relevant parts of the scan repository log:
Examining Bo**a/pro-***-ter
Checking branches...
Getting remote branches...
Checking branch devel
Getting remote pull requests...
Checking branch master
‘Jenkinsfile’ found
Met criteria
I have validated that the devel branch has a Jenkinsfile and that the Jenkinsfile is valid.
I can't figure out how to solve this. Any suggestions would be great.
Some plugin information:
github 1.28.0
branch 2.0.11
docker-common 1.13
docker-pipeline 1.17
git 3.6.0
git client 2.7.0
git server 1.7
SCM API 2.2.3
Jenkins version 2.73.2
I had this same problem with BitBucket Server and Jenkins when using Blue Ocean (BitBucket Server plugins). The branch would not create in Jenkins. I noticed that the branch commit and the pull request (PR) had a successful build. It seems that if Jenkins detects a PR is opened for a branch, it will not create the branch on the Jenkins side. Once I deleted the pull request from BitBucket Server, Jenkins registered the branch and it showed up. Would be better if the branch showed up, had no builds and referenced the Pull request Jenkins job!
Sorry for taking so long to answer this:
I did a plugin upgrade to the latest version of all of the plugins in my Jenkins.
That solved my issue.
I think we might found an answer (or problem causer).
In our case we automatically restarted Jenkins once a day in either in the shut down or boot up process branches went missing.
The amount of missing branches declined significantly after keeping the Jenkins running all the time.
Detected unsupported subitem repo » develop, skipping
In my case I just deleted the develop pipeline(by clicking its link on scan branch log page) and rescan, all worked.
It seems while performing scan it probably point to an obsolete hash in Git preventing Jenkins job to scan correctly.
I just set up Travis CI and I noticed that every time I push a branch to the remote repo, it kicks off a build. From my reading of the docs, this is not expected behavior...it should instead only kick off builds when a pull request is opened and on subsequent pushes to that branch.
Also, when I do open a pull request, it kicks off two builds, as shown in the
image.
What I want is the following:
push remote branch (Travis CI does nothing)
create PR (Travis CI kicks off 1 build)
push commit to the branch (Travis CI kicks off 1 build).
Does anyone know what additional configuration is required to achieve this result? Many Thanks.
The expected workflow can be achieved by disabling the "Build Pushes" feature as described here: https://blog.travis-ci.com/2014-03-05-repository-settings/