• Debra (unregistered)

    pacman -S first

  • Rob (unregistered)

    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.

  • (nodebb) in reply to Rob

    Running apt-get or apk should already fail due to missing permissions

    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

  • (nodebb) in reply to Steve_The_Cynic

    It's running inside a Docker container, so normally everything runs as root.

  • Industrial Automation Engineer (unregistered)

    I'm mostly interested in why the normally competent coworker added this to the codebase. Decafinated? Two-weeks notice? The CEO's son insisted?

  • AzureDiamond (unregistered)

    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

  • (nodebb) in reply to Dragnslcr

    OK, TIL, thanks.

  • Rob (unregistered) in reply to Dragnslcr

    It's running inside a Docker container, so normally everything runs as root.

    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.

  • (nodebb)

    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.

  • (nodebb) in reply to thosrtanner

    ||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.

  • Sandra from InitAg (unregistered) in reply to Ralf

    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.

  • LZ79LRU (unregistered)

    Honestly this looks to me like someone pushed test code. And let he here who newer done that cast the first stone.

Leave a comment on “Continuous Installation”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article