3 ms·

Noo, builds shouldn't rely on Jenkins. I root for the previous admins.

by strictfp 10y ago

kirubakaran 10y ago
Can you please go into more detail?
- strictfp 10y ago
  My view is that the build which runs on the CI server should be close to identical to the build which a dev can run on a workstation. This way you don't have to check in anything to debug build errors. The build may complement the normal build, in ways such as emailing, but shoulldn't modify it.
  - gargravarr 10y ago
    I will agree with you there; the builds run through our CI servers can't be run on a local workstation. I'm still not sure why, but the build script simply will not work if run locally. To run from the command line, I have to invoke msbuild and nodejs manually. This isn't a big problem since most devs build through Visual Studio anyway, but I do fully understand your argument.
    - strictfp 10y ago
      Currently we have a docker-based test runner which works differently on the CI server. It should be identical, but of course the bugs you trigger are usually the difficult ones caused by unexpected timing problems, file permissions or subtle component interaction. If you get stuck trying to fix an error only triggered on the CI server, it's a huge time waster and commit log polluter. Especially if the security policy is such that you aren't easily allowed shell access on the build slave. If devs have full access, it's not so much of a problem actually. But still very annoying whe you are dependent on your VCS and CI server to build your project properly.
gargravarr 10y ago
By all means. Please picture the following: -A folder full of batch files, each 2,000 lines long, that actually coordinate the builds -A folder full of .exe's like 'findAndReplace.exe', 'EmailBuildBreakingAuthorsFromSVN.exe', replicating native Jenkins functionality, written in-house -SVN.exe must be installed on the build node; if the build fails, the working copy is usually locked and must be manually Cleaned Up -All build nodes run Windows XP Pro (including the Jenkins master) This is what I had to deal with when I took over the cluster last year!!! For the record, the whole cluster now runs on Win2012 with regular security updates, and most builds use the .Net plugin to build the VS project using msbuild. Those that can't, use Powershell scripts. It has been a VERY long road...
- strictfp 10y ago
  Ok, I wouldn't go that far. Also, windows builds are a pain :)

Noo, builds shouldn't rely on Jenkins. I root for the previous admins.

kirubakaran 10y ago

Can you please go into more detail?

strictfp 10y ago
My view is that the build which runs on the CI server should be close to identical to the build which a dev can run on a workstation. This way you don't have to check in anything to debug build errors. The build may complement the normal build, in ways such as emailing, but shoulldn't modify it.
- gargravarr 10y ago
  I will agree with you there; the builds run through our CI servers can't be run on a local workstation. I'm still not sure why, but the build script simply will not work if run locally. To run from the command line, I have to invoke msbuild and nodejs manually. This isn't a big problem since most devs build through Visual Studio anyway, but I do fully understand your argument.
  - strictfp 10y ago
    Currently we have a docker-based test runner which works differently on the CI server. It should be identical, but of course the bugs you trigger are usually the difficult ones caused by unexpected timing problems, file permissions or subtle component interaction. If you get stuck trying to fix an error only triggered on the CI server, it's a huge time waster and commit log polluter. Especially if the security policy is such that you aren't easily allowed shell access on the build slave. If devs have full access, it's not so much of a problem actually. But still very annoying whe you are dependent on your VCS and CI server to build your project properly.

gargravarr 10y ago

By all means. Please picture the following: -A folder full of batch files, each 2,000 lines long, that actually coordinate the builds -A folder full of .exe's like 'findAndReplace.exe', 'EmailBuildBreakingAuthorsFromSVN.exe', replicating native Jenkins functionality, written in-house -SVN.exe must be installed on the build node; if the build fails, the working copy is usually locked and must be manually Cleaned Up -All build nodes run Windows XP Pro (including the Jenkins master) This is what I had to deal with when I took over the cluster last year!!! For the record, the whole cluster now runs on Win2012 with regular security updates, and most builds use the .Net plugin to build the VS project using msbuild. Those that can't, use Powershell scripts. It has been a VERY long road...

strictfp 10y ago
Ok, I wouldn't go that far. Also, windows builds are a pain :)