Hi I've recently upgraded my version of Jenkins from version: 2.263.4 to 2.346.3.
I've noticed the Build Parameters for my job, are noticeably less compact than the previous version.
To compare, old Pipeline build parameters:
New Pipeline build parameters:
For the new String parameter name, description and value are all rendered on top of each other. Whereas before the value was directly across from the name, and the description was below the value in a smaller font.
To me the new rendering layout is far less clean, and is also more confusing when you have builds with a lot of parameters.
Is there any way to revert back to the old style with the new version of Jenkins?
Related
I am using Entity Framework Code First migrations to control my database versioning. We have encountered a critical issue in production, which was already noticed and fixed in QA environment, but now needs to be applied to PROD.
The problem is that current latest PROD migration is far not the one that precedes the one we need to apply to fix the issue. I.e., the latest one in PROD is, for example, Migration1. Since that, we have developed Migration2, Migration3, ..., MigrationN-1, MigrationN, MigrationN+1, ... We need to apply MigrationN to PROD, but we cannot apply all intermediate ones, as they are not yet releasable (we are sure, though, that MigrationN can be applied to PROD, as it is not based on any of intermediate ones).
We can cherry-pick the relevant application code changes and prepare a hot-fix deployment, but we cannot do the same with migrations, as if after that we want to have a regular deployment, all intermediate migrations (2 - N-1) will then be ignored, if I get it right.
What should we do?
I'm storing information in a custom property sheet for one of my custom products (I'm then using that information in a javascript file). I want this product to uninstall cleanly, but I can't seem to figure out how to remove a custom property sheet on uninstall using genericsetup. I know that remove="True" doesn't work, but I'm not having much luck figuring out the correct way (or any way for that matter) for removing this. Any suggestions would be greatly appreciated.
This is confusing for at least two reasons:
We have both "old style" and "new style" technologies actively in use. Old style refers to Extensions/Install.py (Python code) and new style refers to profiles/default (GS XML + setuphandlers.py Python code).
Successfully installing and uninstalling add-ons in all possible cases still requires the use of both old and new style technologies.
If you don't care about uninstall, you never need to use Extensions/Install.py. If you do care about uninstall, create an Extensions/Install.py with install and uninstall methods.
Also create an "uninstall" profile (in addition to the "default" profile) e.g. profiles/uninstall. Configure the Extensions/Install.py:install() method to execute your "normal" profiles/default steps on installation. Now comes the "fun" part.
Because some technologies can be uninstalled "properly" via GS i.e. they respect the remove=True parameter, your Extensions/Install.py:uninstall() method should execute the "proper" GS profiles to do the uninstall. But if your add-on uses technologies that cannot be uninstalled "properly" via GS i.e. those that do not respect the remove=True parameter, then you will need to write Python code to perform the uninstall.
See:
http://plone.org/documentation/kb/genericsetup/creating-an-uninstall-profile
for more information.
When we were using SVN, we'd always print at the footer of our pages: "Revision XXXX". I've been looking, but I can't figure out how to do the same thing with TFS. Can anyone offer some pointers?
In case this matters: we're using ASP.NET MVC. I'm guessing it doesn't matter, however.
You can use the default version system for assemblies to track revisions number without adding anything in TFS.
If you use the Major.Minor.* format in your AssemblyInfo's AssemblyVersion attribute (e.g. [assembly: AssemblyVersion("1.0.*")]) it will generate a version according to the following format:
Major.Minor.Build.Revision
where
Major = Your value
Minor = Your value
Build = Number of days since
2000/01/01
Revision = (Number of seconds since midnight on the day
specified in Build) / 2
This will give you an always increasing number which gives you precise information on build date and time.
To use these values in your code, you can simply recover the version using Assembly.GetExecutingAssembly().GetName().Version.
You can update version number of projects in AssemblyInfo.cs using assembly versioning tools/techniques like this. Version number of an assembly can be updated based on TFS changeset number. Version number then can be displayed in application.
At least when it was released, TFS didn't allow symbol replacement in files which is what I think you're after. I'm not sure if that has changed in more recent versions.
Changeset != Version
That being said, you can add a setting in web.config that holds the version number, and display that on the page. The version number can be updated as part of the build process, but it will not correlate to a changeset.
I should probably add that this can become a circular problem. If you get the latest changeset number for a project, then add that to the config (as named above), then checkin, you are no longer displaying the latest changeset. Adding 1 to the latest changeset is not a guarantee either, because something can be checked in while you are updating the files.
We ended up using a MsBuild task that searches for a particular string and replaces with the appropriate value (not necessarily the revision number).
The task runs as part of our build templates and puts the revision number in all the files that have the token present.
what's your strategy to increase build number?
Most software has a hierarchy of version numbers:
The "marketing" version number (like "Windows 7")
The major version number - usually incremented when there's a major new version that breaks some compatibility with a previous version, adds a major new capability, requires purchasing an upgrade, or more.
The minor version number - upgraded every time there's a bug-fix or minor feature enhancement that's released to the public
The build number - this should be incremented every time any change is made to the program, so that if someone finds a problem in a nightly build or beta-test version, you can identify exactly which version was being tested. This number is often a revision number directly from your version control system like Subversion, or a timestamp, or something similar that makes it easy for you to roll back the code to that version if necessary.
All the dlls must have the same version number for one release.
Build number consists of "MajorVersion.MinorVersion.BuildNumber.Revision", usually I keep the Revision Number to be 0. Only the first 3 numbers are changed.
For every nightly build, BuildNumber will be incremented automatically. I will manually increase majorversion and minorversion if the changes are sufficiently big.
Every checkin should be tagged a version, use the subversion current version as the part of the build exe version.
It's quite reasonable to increase the build number for just every build. This way testers can tell more exactly which build they find a bug in and when it is verified to be fixed.
We have a build number that's incremented on every build (formal or otherwise). We use a CruiseControl.NET labeller for this.
We have a version number that's incremented by hand only on formal releases, and we define that centrally in one of the CC.NET scripts, which are held in source control.
Like everyone says, increment the build number for every build. We set the major/minor numbers by hand when we do a branch, a branch is usually done a few weeks before release, then that branch gets regression tested. Builds done on the branch still get incremented though.
We are approaching the initial release of a new product at our company, and I am trying to determine the best method of managing the versions of all of the different components and cross referencng those components with the marketing department version of our software. For various reasons, marketing has determined that the initial release of our product will be 10.1, however all of the components will initially start out at 1.0.0. Through normal bug fixes and patching and continued development work, the different components will no longer be at the same version number, so when marketing department decides it's time for version 10.2, it might contain 1.1.54, 1.2.32, 1.8.2, etc. Obviously, I could use a simple spreadsheet, but that isn't exactly the most user friendly method, and has issues for our tech support people to cross-reference the component versions (the customer is really only aware of version 10.1, 10.2, etc).
Is there a more "professional" method for this, or is a simple spreadsheet the best option?
The main principle I'd suggest is: Use the simplest scheme you can.
Consider making things easy for yourself, your marketing department, and your users.
When you do a release, increment the major/minor version number, and then stamp that across all your components. So in the 10.1 release, all your assemblies will have version numbers 10.1.xx.yy
Then if you really want to complicate matters with different versions within a release (e.g. for minor patches/updates, different customer variants, or just for internal daily or CI builds), then use the xx.yy fields. (In many cases you can get the compiler to automatically fill these two fields in with the date/time of compilation, for example).
This means you have a meaningful "marketing version" which is actually linked to your code versions (so you and marketing can talk about a particular release without any chance of confusion), and you can add extra information (e.g. build date) if (and only if) needed on the dev side.
edit: P.S. Even if a component doesn't change, rebuild it with the new version number. Trying to track a hundred out-of-sync version numbers is an avoidable nightmare.
At places where I've worked, we'd force the software version number to match the official, public (i.e. Marketing's) release number: if they wanted to ship "10.1" then that's what we'd set the software's version resource to, as part of the release build.
Why not leave all components at their "random" version numbers and create one super tag/label with the marketing version that encompasses all components? This allows you to keep updating the components in-between marketing builds and increment their build versions (without having to go to 10.1.001, 10.1.002 that may be visible to the customer) and also keep track of the marketing build. Also, what happens if you update some components for the next marketing build, but not others? Do you need to build those components just to update the version number?
Depending on your source control system, you should be able to easily create a release with a specified name/version that contains all of these components at different versions.
You should also just need to update one properties file with the marketing build number so it shows on all about screens, splash screens, tool bars, etc. If you don't have such a configuration in place, you may want to move to such a system. This allows for easy changes to the customer visible number while maintaining all component build numbers. Besides, what happens when marketing determines that the next version isn't going to be 10.2, but "Crimson?"