I'm using a Jenkins pipeline project to build my sources.
When checking Lightweight checkout, I'm getting next output:
Lightweight checkout support not available, falling back to full checkout.
I'm using the latest version of Git.
Could the reason be that the Jenkinsfile is not on the root of the project?
Can't really find lots of documentation on this feature.
Related
I'm trying to set up a build using Multibranch. I'm basically having the same problem as stated here, but our SCM is Subversion. The Bug in the Bitbucket Branch Source Plugin as described here can therefore be ruled out, especially since our Jenkins has the newest version installed anyway.
I tried to find a similar ticket regarding my problem, but couldn't find one, so here I am.
As this particular project is configured in a way that configuration files (including something like the Jenkinsfile) are to be stored in a subfolder, I don't know what else to try, apart from configuring individual jobs. I'd rather stick to using Multipipelines, however, as they help keeping the build jobs tidy.
We are attempting to reference a shared library in Jenkins in a pipeline using the syntax described here with #branch_name syntax. We have the "Allow Default Version to be overwridden" setting set. Yet, the pipeline ignores changes in the branch, and uses the version of the library in master. Any advice on additional settings/configuration needed or suggestions to make this work are appreciated.
We tried this syntax specifically: #Library('library_name#feature_branch_name')
Additionally, I specifically see an entry in the console output: "Loading library library_name#feature_branch_name". Yet, somehow it ignores the changes that have been commit in that branch, instead running against master.
My jenkins jobs started to disable by themselves when the svn checkout fails. I explored previous builds and they never disabled when failed. This new behaviour is not desired for me.
The message in the new build log is as follows:
...
One or more repository locations do not exist anymore for myJob1, project will be disabled.
The project has been disabled
ERROR: Failed to parse svn info for 'repourl'
...
I downgraded the jenkins Subversion plugin which was recently updated, and the multi scm plugin as well. However, the problem remains.
Any suggestion?
That message is coming from the Blame Subversion Plugin. Is it possible you recently installed that plugin? Or that you recently turned on SVN blame as an option?
I think this is an undocumented(?) behavior of the Subversion Plugin to automatically disable a job if the SVN URL is not valid (anymore). This behavior seems to be implemented for several years now, as this discussion from 2012 indicates. I just learned about this behavior only after moving a SVN project to a different folder which caused my project to be disabled. I did not find any information on how to disable this behavior.
Update 2021/09:
The behavior is apparently still present and there seems to be no way to disable it.
There is a corresponding feature request on the Jenkins JIRA though: JENKINS-10922
Please vote for this feature request!
I'm currently setting up continuous integration using TFS/Visual Studio Team Services (was VS Online), and I'm using the Team Foundation Build 2015 tasks. So not the XAML builds.
I'm using it to build a Xamarin Android project, but that's pretty irreverent I guess,
The process should be like this:
After a check-in:
TFS should download the sources
TFS should increment the version number within AndroidManifest.xml
I've managed to do this by making a PowerShell script for this.
After the AndroidManifest.xml file is modified, it should be committed back into the TFS repository
Then the rest, build deploy into hockeyapp etc
The first steps are all configured, but I'm struggling with the commit part. How do I get TFS to commit the file? I don't really see any task suitable for it. I've tried using the Copy and Publish Build Artifacts Utility - But that did not seem to work, and I'm not even sure if that's the right utility
I'm using the default hosted build agent btw. Any help would be appreciated
Warning
I do want to point out that checking in changes as part of the build can lead to some features of VSTS/TFS not working. Association of work items to the checkin, sources and symbol generation, tractability from changes to build to release and integration with Test Manager, remote debugging, will likely not yield the expected results because the Changeset/commit recorded in te build may not match the actual sources. This may lead to unexpected funny behavior.
Also, if any new changes have already been committed/checked-in after the build has started, the version number may be updated in Source Control for code that was not actually released under that version.
So: First of all, it's considered a bad practice to change the sources from the build process.
Alternatives
There are better ways of doing it, one is to use the build version (Build_BuildNumber or Build_BuildID variables). Alternatively you an use a task like GitVersion to generate the semantic version based on the branch and tag in your git repository. That way your build will generate the correct version number and will increment the revision in case the same sources are built multiple times.
I understand, but I still want to check in my code as part of the build
If these things don't work for you and you still want to check in the changes as part of the build, you can either use the TFVC Build Tasks if you're using TFVC or use the Git Build Tools to add the remote to the local repository and then use the git commandline tools to commit and push the changes back to the repository.
These extensions require TFS Update 2 to install. But you can push the individual build tasks using the tfx commandlien tool. For the TFVC tasks the process is explained here.
On mac
On the mac it's going to be harder since you're using TFVC. My TFVC tasks leverage the TFS Client Object Model and Powershell to communicate to the TFS Server. The tf.exe tool doesn't even work on windows when you're in the context of a build, which is why I need to call into the VersionControlServer object directly. Given I'm dependent on these technologies, the tasks won't run on a Mac or Linux agent.
You could try to see whether the Team explorer Everywhere X-platform commandline works from the build agent (using a shell script). I have no way to test this on an actual Mac.
Given the cross platform nature of your project I'd recommend to move to Git, it integrates into XCode and Android Studio, making it easier to do a native UI or build on top of native libraries.
Alternative 2
You could setup a build which does the required changes to the code and then checks in the modified code. Then have a (CI) build run the Android and the Mac builds using the modified code.
I currently have Build User Vars Plugin 1.1 installed in my Jenkins. Since version 1.1 of the plugin, there has been some important changes to the plugin code, and I want to pick them up. The question is what is the least amount of work to package up the hpi/jpi file that I can push on my Jenkins install that will contain latest changes.
It's fairly easy to build a plugin locally; you can then upload the hpi/jpi file to Jenkins via the Advanced tab in the plugin manager.
See the Jenkins plugin tutorial for detailed steps.