I am trying to adopt Bazel for a project which was recently converted to a monorepo.
(I am VERY new to Bazel and have no mentor handy, please excuse me if the questions I ask are answered with "rtfm"; I am happy to do so, please point me to the manual.)
This monorepo contains a bunch of libs and binaries. When a certain tag is set, the goal is to build everything (as in bazel build //...), pack all the binary files into a zip and attach the created archive to a GitHub release.
I am comfortable with GitHub Actions, triggers and the releases itself, however I am not sure what an appropriate approach would be to create the archive containing all binaries via Bazel. Can anyone point me in the right direction?
You should go through below links #1 #2, #3, #4.
I want to display non-code differences between current build and the latest known successful build on Jenkins.
By non-code differences I mean things like:
Environment variables (includes Jenkins parameters) (set), maybe with some filter
Version of system tool packages (rpm -qa | sort)
Versions of python packages installed (pip freeze)
While I know how to save and archive these files as part of the build, the only part that is not clear is how to generate the diff/change-report regarding differences found between current build and the last successful build.
Please note that I am looking for a pipeline compatible solution and ideally I would prefer to make this report easily accessible on Jenkins UI, like we currently have with SCM changelogs.
Or to rephrase this, how do I create build manifest and diff it against last known successful one? If anyone knows a standard manifest format that can easily be used to combine all these information it would be great.
you always ask the most baller questions, nice work. :)
we always try to push as many things into code as possible because of the same sort of lack of traceability you're describing with non-code configuration. we start with using Jenkinsfiles, so we capture a lot of the build configuration there (in a way that still shows changes in source control). for system tool packages, we get that into the app by using docker and by inheriting from a specific tag of the docker base image. so even if we want to change system packages or even the python version, for example, that would manifest as an update of the FROM line in the app's Dockerfile. Even environment variables can be micromanaged by docker, to address your other example. There's more detail about how we try to sidestep your question at https://jenkins.io/blog/2017/07/13/speaker-blog-rosetta-stone/.
there will always be things that are hard to capture as code, and builds will therefore still fail and be hard to debug occasionally, so i hope someone pipes up with a clean solution to your question.
I'm currently looking at a TFS build server setup & I was trying to set up a process whereby I can set up a build template to build to a folder based on the version number of a .NET assembly that's part of the build (As per the assemblyinfo.cs file). I've got it building to the standard looking folder ("Release_20130502.1"), but that's not exactly useful in 4 months time when we want to find the build for the v1.1.0 release.
Basically I want to make a special build template which will create a major release, and I'd like the folders it makes to be more noticable as versions rather than timestamps. I'm also hoping to automatically label the release as that version too. I know how to copy the files & make labels, but I'm not sure how to get at the version numbers.
I'd also love if I could get this into the Build Name recorded in TFS somehow but I suspect that might be a bit optimistic.
Does anyone have any idea how to do this (Or alternatively any other technique that'll get me easily recognizable release version builds)?
Take a look at build number format property for build definitions this is used to generate the build number and in turn the build folder during build and label in sourcecontrol if its enabled, you can modify this manualy to pass desired build number. The mentioned drop folder can be manually given as well. And you can always copy the folder after build by hand.
You can use revision variable to create something that works similiar to what you want, Revision number gets incremented if there is build with same name in system
Format: Release v1.$(Rev).0 - this would give you Release v1.1.0, Release v1.2.0, ... on each build
You will have to customize build definition with custom activity for your defined goal to work without manual interaction. However with details you have provided this approach has issues - each project has its own assembly info - which one do you use, what if they are different? This should get you started.
http://www.ewaldhofman.nl/post/2010/04/20/Customize-Team-Build-2010-e28093-Part-1-Introduction.aspx
You can take a look at these may find something useful
http://tfsbuildextensions.codeplex.com/
It all comes down how often do these build take place, if its week or more then doing it by hand is perfecly valid aproach in my book.
I have an environment where I'm building several library solutions in TFS. At the end of the build process the script packages them into a NuGet package and pushes them to our local feed.
Now we can include these libraries, which change little day-to-day, in our upstream projects.
These libraries as well as our upstream projects generally are branched at the same version. Basically the trunk is our evolving latest version. Say before branching the trunk is 3.0.0.123, 123 being a running build number. At some point we mark the current trunk as what we're going to release and branch it. The version number of the trunk at the time of the branch becomes the version of that branch and we would increment the version in whatever appropriate manner for the trunk to what we would feel is likely going to be the next release (say 3.1.0.456).
This presents a slight oddity to how we'd like to use NuGet. We would want that the branch, 3.0.0.456, use the lateset library from the branch (perhaps 3.0.0.457) and the trunk to use the latest from the trunk (3.1.0.789)
So what this basically boils down to is can we setup the versions for a solution using NuGet to be similar to the manner NuGet uses when defining dependencies within a package?
Ideally, I'd like to tell the branched upstream application to use [3.0.0.456, 3.1) and the trunk to use latest (no version). In this scenario it would pick up the branch would pick up the next branch build (3.0.0.457) and the trunk would pick up whatever the last NuGet package that was published to the feed.
The only idea that I've come up with as a possible solution is using parameters for the build template and using that to update the package.config file before the NuGet targets are run.
I appologize if this should go on SuperUser or elsewhere...
After doing some digging to have my build do some auto creation of packages for our library projects I came to the (wrong) conclusion that this was a limitation of NuGet. I parsed their source for any XSD documents to describe their XML so that I could see how their nuspec worked.
While I had their source I started looking into how I could modify the package.config file to accept their schema for limiting versions. After some digging I found an attribute that can be added to the package node in package.config: allowedVersions. This is exactly what I was looking to add!
Once I had this piece of information I was able to dig a little deeper into how it was implemented. Turns out that this functionality has been around for a while and is even documented on their docs site: http://docs.nuget.org/docs/reference/versioning
It is in the dependency versioning guide located at the bottom. I must have completely glossed over it or never read that far!
Turns out that this was a non-issue and the only problem was my ignorance. Just a reference for any Googler's out there that land on this page!
SOURCE (LOCATED AT BOTTOM OF PAGE): NuGet Versioning
It seems that all of the initial Google results for "using subversion with xcode" are actually just tutorials for installing and configuring svn and Xcode, as opposed to actually using the two (i.e. interacting with svn via Xcode's GUI).
Is anyone aware of a good guide that teaches the tricks and pitfalls of working with svn via Xcode's GUI? Something that bridges the gap between the most excellent Version Control with Subversion book and the Xcode IDE (as in pure Xcode GUI without any terminal command use)?
Edit:
We all love our terminal commands, and we all love Eclipse but (and I mean this in the nicest possible way) neither is really the point of the question. I’d prefer to use svn via Xcode’s IDE instead of via terminal just as I prefer (well, for this case) to code in Xcode’s IDE instead of using vim and gcc. Apple engineers spent a good bit of time implementing that SCM menu in Xcode; someone has to have seen a usage guide somewhere.
I used this page as a reference for setting up my XCode projects with SVN. It is a good starting point, but I'll give a short walkthrough of what I did (since the page isn't really all that helpful!).
A couple notes: I'm using XCode 3.1.2 and Subversion 1.4.2. I've heard of problems with using SVN 1.5, but there are ways around that which I wont get into.
First off, I had a repository already set up and created the XCode project afterwards.
In XCode you need to set it up to know about your repository using the SCM tab in the preferences window. Enter:
A Name (this is arbitrary and used for reference with XCode)
The scheme (http or svn)
The host (i.e. svn.example.com)
The path (the exact path to the SVN repository located on the host)
The port (only if it isn't the default)
And a username and password used to access the repository.
The URL will be auto-filled as you enter the other fields. Hit "OK" when all the fields are good and XCode says it can connect.
Then open your project and do a "Get Info" (Round blue icon with an exclamation mark) on the project itself. Under the "General" tab down at the bottom is an option for SCM, select the repository you made in 1 and close the window.
Now open SCM in the menu-bar and go to "Repositories." Hopefully you've built your repository right using branches, trunk, and other directories at the base level because XCode doesn't have support for checking out the root directory. So go one directory at a time down the list and click the "Checkout" button and select a directory to check it out to (I recommend a "Code" or "Source" or "SVN" directory inside your XCode project directory). You cannot checkout multiple directories at once, but you can tell the next directory to checkout before the first has finished and XCode with queue the commands.
Once that is all done go back to your XCode project window and "Add -> Existing Files..." to your project. Select the directory you've checked out the repository to and I recommend using the "Create folder references" option instead of the "Recursively create groups" option because added and removed items will be automatically reflected in a Folder Reference but not in a Group.
Now you've imported your SVN repository into an XCode project. From here any time you make a change, simply Right-Click (Control-Click if you only have 1 button) in the file and at the bottom of the context menu are the SCM options for comparing, committing, updating, and discarding (reverting) the file. You can also use the SCM menu in the menubar for file or project-wide updates/commits/reverts.
I second the comment by the_mandrill, SVN support from within XCode is very limited, especially if you're used to Eclipse.
I also don't understand why everyone seems to need visual clients. I keep a terminal window open on my project directory and I have no problems interacting with SVN from the command line.
I know this is not quite what you asked, but I wouldn't rely much on the use of SVN from Xcode as what you can do with it is very limited. It's useful for being able to do a diff or annotate direct from the IDE but not a great deal else. I don't think it's any substitute for using a separate standalone client such as SmartSVN or Versions.
You also have to jump through a number of hoops to get Xcode to work with SVN version 1.5 onwards, so that's something to be aware of before installing a standalone client. If in doubt, check out a sandbox first.
Here is one of the best tutorials to configure subversion in XCode - http://iphonedevelopment.blogspot.com/2009/03/version-control-is-your-friend.html
It also teaches even to create repository in local MAC.
if you want to work with svn through a gui interface then i suggest you use eclipse + subclipse plugin (which have more features and much more reliable and easy than svn on xcode)..
you will work in xcode as normal but you will use eclipse only as an svn client (by creating a general project in eclipse and make it points to your xcode project directory )
and here is a tutorial of how to install subclipse
A lot of people have problems using the build in svn client, especially to get a new project into svn and that it works.
I created a straight foreward tutorial on how to do this, along with a very well known pitfall (works for Xcode up till the latest version of xcode incl. Iphone 4 sdk)
http://www.sodeso.nl/?p=599
I myself looked up for some good resources and one of the best I've found is a quite recent video from the WWDC 2012 :
Sign in here if it's not already the case : https://developer.apple.com/videos/wwdc/2012/
Then there is a video called :Session 411 - Source Control Management in Xcode
It explains how to use version control both with GIT and Subversion. It's really nice !
Hope it helps!
As has been mentioned in many other answers, the svn client with Xcode is quite weak (and that is being kind).
Personally, I think that running Eclipse just to get access to a svn client is a bit heavy handed.
I would suggest two answers:
Use a dedicated svn client for the Mac (Versions and Cornerstone are both very good, albeit not free... there are free ones, such as svnX)
If you are not wildly comfortable with the terminal, you can script a couple of the key commands that you want to use and add them to your Xcode user scripts folder, then you can trigger them from a menu item of from a keystroke, just as if you were using the Xcode native client. There's a ton of examples on how to do this available via Google.
I came across these - no idea how well they work, but wanted to add some resources if I could:
http://www.macresearch.org/tutorial-introducing-xcode-30-organizer
http://developer.apple.com/tools/subversionxcode.html
With XCode4 you can perform almost all of your SCM tasks from within the IDE itself, this is a great step forward.
Here is a link to the official guide :
http://developer.apple.com/library/mac/#documentation/ToolsLanguages/Conceptual/Xcode4UserGuide/SCM/SCM.html#//apple_ref/doc/uid/TP40010215-CH7-SW26
Unfortunately you still have to use the Terminal command line to add a new project to SCM, this is also clearly documented in the link above.
What it does not tell you is that you also need to manually add ignore instructions to your SCM configuration otherwise you are going to end up with user settings and build outputs in your repositories. I am currently figuring out the list and I will update this answer once I have it finalised.
PS :
I know this question is quite old now but I have added this for those of you who arrive here looking for answers like I did.
PPS :
Terminal command line increases probability of human error, takes longer, is more complex and is less transparent to end users. Overall the omission of being able to add projects to SCM from within XCode is poor design, I expected better from Apple who are usually good at simplifying UI. For the command line fans out there you might feel L337 but try managing a team of programmers and being responsible for their code, command line is not your friend.