The worst thing about Jenkins is that it works (2019) • Hacker News Board

Re: The worst thing about Jenkins is that it works (2019)

#271

Post by j1elo » Tue, Dec 05, 2023, 9:11 PM UTC

growse wrote: post #266

j1elo wrote: post #257

Earlier quoted context omitted.

C++ with templating can take a while to compile, so for caching my build system would include mounting a Docker volume with contents of ~/.ccache/. This was well integrated with the rest of the scripts, so it would work equally fine if I ran them in my laptop or in the CI runner. My point is that I really don't believe that CI systems provide anything so unique that it couldn't be also provided by local software in a…

> My point is that I really don't believe that CI systems provide anything so unique that it couldn't be also provided by local software in a developer's laptop. If the question of "how do I build this in my laptop" is "you cannot, must use CI because we truly require some of its features", I'd consider that an ops failure. So I do agree with this. But I think there's nuance here. The job of producing a build artifac…

Thanks for expanding on your point of view. Now that I read you, I'd say that we fundamentally agree.

My experience has been to use carefully constructed Docker images that have the required dependencies to build the project. This removed the need for installing everything in the correct version on each dev system, and ensured a commonly shared base system on which to build stuff.

However I agree that a "context" can have lots of moving parts, and I was disregarding most of them as "exercise for the reader" aka. devs ought to know what they're doing if they wanted to build locally. CI can help a lot with that.

Re: The worst thing about Jenkins is that it works (2019)

#272

Post by nijave » Thu, Dec 07, 2023, 10:15 PM UTC

codethief wrote: post #262

JeremyNT wrote: post #239

Earlier quoted context omitted.

This is definitely possible. We've been building an image in one phase and then running it in subsequent phases for years with gitlab. I think you are going about this wrong. Are you generating an image tag dynamically? When you are tagging the image, make sure that you generate the tag deterministically based on information that is available to gitlab when the pipeline is created. So for example, you could use the t…

My apologies, I misspoke: I wanted the image tag not to be $CI_COMMIT_SHA but to be a hash dynamically generated from certain files in the repo. The issue is that IMAGE won't accept a dynamically generated environment variable (passed from job to job via a dotenv artifact).

I think you could just jam anything you need in pipeline yaml from the dotenv file into outputs/variables then do something like this https://stackoverflow.com/a/71575683/2751619

Re: The worst thing about Jenkins is that it works (2019)

#273

Post by codethief » Fri, Dec 08, 2023, 11:21 AM UTC

nijave wrote: post #272

codethief wrote: post #262

Earlier quoted context omitted.

My apologies, I misspoke: I wanted the image tag not to be $CI_COMMIT_SHA but to be a hash dynamically generated from certain files in the repo. The issue is that IMAGE won't accept a dynamically generated environment variable (passed from job to job via a dotenv artifact).

I think you could just jam anything you need in pipeline yaml from the dotenv file into outputs/variables then do something like this https://stackoverflow.com/a/71575683/2751619

No, this doesn't work. Also note that the StackOverflow link is about Github Actions, not Gitlab CI.

Re: The worst thing about Jenkins is that it works (2019)

#274

Post by Tainnor » Fri, Dec 08, 2023, 1:08 PM UTC

MereInterest wrote: post #255

Tainnor wrote: post #251

Earlier quoted context omitted.

Just to give some examples: - your code is using private dependencies, so you can't build the code without authentication - you have some integration tests that use test containers using private docker images, so you need to do a "docker login" before running tests Locally, that would work because you're locally authenticated (and likely have all dependencies already installed etc.)

Ah, I think I see. There is a dependency in the code that requires copying some external resource in order to build/run locally. The developer's local environment may have a different version of that resource than the CI, so a bug ends up not being reproducible. The developer may not run the CI directly, because the developer's access tokens should be separate from the CI's access tokens. I was picturing a case where…

> I was picturing a case where the CI was allowed privileged access to a resource to which developers were not allowed access at all.

That's also possible. Imagine a pipeline which carries out a deployment in an environment where normal devs are not allowed direct access to production machines / cluster (might happen in larger companies).

Re: The worst thing about Jenkins is that it works (2019)

#275

Post by jakjak123 » Sun, Dec 10, 2023, 6:46 PM UTC

hardwaresofton wrote: post #55

Gitlab CI is still the best CI in the game IMO, but GitHub Actions gives it an incredible run for it's money because of how easy action re-use is. I meant to make a blog post about this, but here's a good a place as any: GitLab absolutely innovated many hard parts of CI/CD as a platform-native piece, but it feels like they lose slightly to GitHub on what GitHub does best -- social virality for developers. The problem…

Very good summary. I think both Gitlab CI and Github Actions are very good, but I think gitlab ci is more practical because of how easy it is to build custom advanced pipelines vs the great re-use of github actions.