- Feature Articles
- CodeSOD
-
Error'd
- Most Recent Articles
- Lucky Penny
- Mike's Job Search Job
- Teamwork
- Cuts Like a Knife
- Charge Me
- Que Sera, Sera
- Hot Dog
- Sentinel Headline
-
Forums
-
Other Articles
- Random Article
- Other Series
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
pacman -S first
Admin
If Jenkins is properly setup, installing any tool from a pipeline should be impossible. Running apt-get or apk should already fail due to missing permissions.
Admin
especially since it's launched without "sudo"... (Unless someone has done some sickery(1) with the sudoers file, in which case it's arguable that Jenkins is not properly set up...)
(1) Sick trICKERY
Admin
It's running inside a Docker container, so normally everything runs as root.
Admin
I'm mostly interested in why the normally competent coworker added this to the codebase. Decafinated? Two-weeks notice? The CEO's son insisted?
Admin
the only situation where this is the right thing to do is with github style pipelines that use the same image for everything and you need to get dependencies yourself. even then you know what distro its running on
Admin
OK, TIL, thanks.
Admin
It actually depends on how Docker is started. When the pipeline uses Jenkins' Docker functionality like
docker.image(...).inside(...) { ... }
, Jenkins adds some Docker options. Those include mounting the current directory in the workspace and using it as the current working directory in the image, but also Jenkins' user id and group. That means that the commands inside the Docker container are running as the Jenkins user, not as root.Admin
What's the || true do? I find shell scripts not at all intuitive, so I might be wildly off track here, but either (1) It does nothing or (2) it suppresses error returns so failures will not stop the build.
At best it's pointless, at worst it's going to suppress any errors which is worse than pointless.
Edit Admin
||true
makes sure the commands don't fail, which really has no place in a build file.In fact one wonders why they even need to run YAML linter in the first place. That's more the kind of stuff you put in a commit pre-check hook.
Admin
This was a common trick among older Jenkins users, since it made sure you could continue the build even if your lint step returned nonzero (e.g. if there were errors). Then you could make sure e.g. that your results aggregation step would still run and give you the nice graphs and whatnot. These days Jenkins has builtins for that sort of thing that will set the build status but allow the build itself to keep running.
As for the YAML linter, that was at my request - the project is pretty YAML-heavy, and not everyone always remembers to turn on their pre-commit hooks (you know, the usual problem). Running it in CI is cheap insurance against that.
Admin
Honestly this looks to me like someone pushed test code. And let he here who newer done that cast the first stone.