Using the Build Server to test your code

I was having a nosey at Pull Requests, and I saw one that was titled “Code to get the rest of the team up and running”.

I have a look, and after he sent the initial request, there were 2 other additional fixes along the lines of “fix broken build”. The next day, I checked back and there were 7 other additional fixes, again along the lines of “fix broken build”.

9 attempts.

Clearly, he wrote the code, and didn’t test it at all. Didn’t even build it. He just submitted the code, and let the Continuous Integration build run, and fail. Then run and fail, then run and fail… repeat until we all go insane.

They do say the definition of insanity is to do the same action multiple times and expect a different result.

9 attempts.

Still can’t get over it. At what point do you realise it’s best to actually test your changes?

I guess in his mind, he wanted to check in the code as quickly as possible so he can “get the rest of the team up and running”, but surely you have got to realise your approach isn’t working. When your “quick change” has been spread over 2 days; it is no longer quick.

I love it when people cut corners to save time…but in the end it takes 5 times as long as it would have done if they had done it properly.

9 attempts.

But wait, there’s more. Well, there will always be more because he doesn’t learn from his mistakes.

His next set of changes was to add support to handle a new message. His colleague reviewed his code and left a comment like “this line of code will prevent the message from being sent”. Yes that is right, he is adding a new message, and the message won’t even send. Yet he is sending it for review. Obviously didn’t test it; just coded it blind like before.

So he makes the change, makes some other smaller suggested tweaks. The build fails with Code Analysis errors which he would have found if he had actually built his changes locally. You know, step 1 when you begin to test your changes, and precisely the problem he encountered the week prior with his previous change.

The reviewer makes another comment, doubting some other part of his code would work. He replies:

“I think I will have to abandon this review and get this tested.”
Insane Developer

You know what makes this worse? He used to be employed as a software tester.

Jenkins

There’s a developer that is a massive fan of Jenkins. I’ve never used Jenkins, but he wrote a large post about why he insisted his team migrate to it, and I didn’t understand any of it.

I found it interesting that at first he mentions moving away from AWS CodeBuild because it wasn’t clear if builds were passing or not. I don’t know how this was a problem. The builds are linked to Pull Requests and GitHub displays this clearly.

What I found more interesting is that later on, he then says that GitHub Actions is in its infancy so isn’t as powerful as Jenkins. Sure, but why were you using both CodeBuild and GitHub Actions?

Further to this, one of his advantages of using Jenkins was “Don’t have to pay for GitHub Actions”. Hang on, but you have to pay for a build sever to run Jenkins. How does that even make sense? He was running it on AWS, so was paying Amazon for a dedicated server anyway. I’m pretty sure CodeBuild and GitHub Actions are cheaper to run than a server.

He further justifies using Jenkins with the “everyone else is doing it” line. I’m not even sure if he can verify this claim, but he said “if you look at the big ,key players in the market you will ALWAYS find they have a Jenkins instance”.

He also mentions another team used to use it. Yes that is right “used to use”. Which team was it? The one he used to be in. It was his implementation, and as soon as he switched teams, his old team had binned Jenkins.

I do wish people would use facts in their proposals rather than chatting nonsense to suit their own agenda.

GitHub Actions are Secure

In a previous blog on GitHub Actions, I have mentioned how some people love trendy technology and want to use technology when it may not be suitable.

Today, I was reading some documentation a team had put together which justified why they use GitHub Actions.

A standard team will have their code stored on GitHub, and when new code is ready to be checked in (via a “Pull Request”), a build is triggered on AWS (Amazon Web Services) CodeBuild. If successful, then you can use the built code to deploy to a test system, and to the live server.

The reason specified by Simon why to use GitHub Actions was that it is “self-contained, so is therefore more efficient and more secure”.

I know that GitHub actions use Microsoft’s Azure platform, and I assumed that GitHub store their code on their own servers. So with GitHub Actions, Azure will take the code from the GitHub server and build it, whereas CodeBuild takes the code from the GitHub server and builds it…no difference at all.

Well, there could be a speed difference if Azure is better than AWS or vice-versa, but the claims of “self-contained”, “efficient” and “more secure” is all conjecture.

I did contact Simon and he used some interesting phrasing along the lines of “No idea if it is better or worse, the statement was meant to address the concerns at the time.”

What? He wrote it just to please his colleagues/managers even though it was pure fabrication?

“hey Simon, we need to set up a build process”
“OK, I’ll set up GitHub Actions”
“One thing we forgot to add, security is the utmost priority. We want the most secure tech available”
“Yeah, you cannot get more secure than GitHub Actions, I’ll show you it in this documentation that I wrote”.
“Oh wow, it is really secure”
Fictional dialogue exchange

I did try to research if my claims of GitHub having their own servers is true. This blog is quite old, but back in 2015, they did use their own servers.

“At GitHub we place an emphasis on stability, availability, and performance. A large component of ensuring we excel in these areas is deploying services on bare-metal hardware. This allows us to tailor hardware configurations to our specific needs, guarantee a certain performance profile, and own the availability of our systems from end to end.
Of course, operating our own data centers and managing the hardware that’s deployed there introduces its own set of complications.”
https://github.blog/2015-12-01-githubs-metal-cloud/

Duplicate Builds

Recently, there’s been quite a few odd things our team has done and I haven’t put that much thought into them. So I have either:

approved their Pull Request, putting my trust in the developer that it was the correct thing to do
casually skimmed over something someone else has approved.

Then, when I spend more time in that area, I then think; “what the hell are we doing?”

I was making some tweaks to our build process and then thought “why do we have two builds for every check-in we do?”

So I look at the definitions and it’s basically this:

Build 1	Build 2
Download and install	Download and install
Run linter	Run linter
Run tests	Run tests
	Produce report

build steps

So the second build is just to produce a report, which it needs a valid build to produce. But it could just use Build 1. The sensible thing to do is just to delete Build 1, since Build 2 has the full steps we actually want.

So I ask the developer that set-up these builds and he said “it is quicker”.

So I’m like “what!? how?”

“it runs in parallel”

So? Both builds initially do the same thing, but one has an extra step so Build 2 takes longer. We have to wait until both builds complete before the code can be checked in. If Build 1 fails for some reason (e.g. Unit Test failure), then you are 99% guaranteed that Build 2 is gonna fail, therefore is a waste of time and money. The report can’t generate unless there’s a valid build, so the report may as well just use the existing build. Since they run in parallel, the total time is just the time of the longest running build e.g. Build 2.

He didn’t even seem convinced.