5 ms·

> How often have you or a coworker pushed an empty commit to "re-trigger" the CI? Zero, because unless my dog configured the CI, I’d just click a button to re-

> How often have you or a coworker pushed an empty commit to "re-trigger" the CI? Zero, because unless my dog configured the CI, I’d just click a button to re-run it on the same PR/commit/branch and not “make an empty commit”. End to end testing of large systems with hundreds or thousands of man-years of code in them will be slow because there is a large surface area to test and testing in individual modules doesn’t give the same kind of end to end coverage that testing everything together does. So while pre-commit would be good, I doubt it will replace server CI for all but the smallest repositories.

gusbremm 4y ago
Agreed, but for instance, I am working on a project hosted on AWS where the trigger build action is not allowed for my user. Empty commit is my only option.
- jhugo 4y ago
  So a dog configured your CI then.
  - fionic 4y ago
    Roasted
- cuteboy19 4y ago
  Im sorry but I dont understand the point of such a configuration. Its certainly not security related
  - meowtimemania 4y ago
    Maybe to click a button they’d have to signup for AWS and log into their account. It easier to just push an empty commit
    - Jenk 4y ago
      the workow will be maintained by the CI tool of choice, which can (should) have its own credentials to deploy stuff. There is nothing but semantic differences between a commit trigger or a manual trigger for a given commit.
  - jffry 4y ago
    It can definitely be security related. The exact minimum set of permissions needed for users to successfully use the AWS Console is byzantine and not well documented. AWS managed (example) policies tend to just grant "* on *" type permissions. To carve out minimal permissions, you have to start with nothing and repeatedly attempt to do the action in AWS console, and check CloudTrail to see what got denied. Increase role permissions, lather, rinse, repeat until it works and pray they don't update the console and break you again. It's possible that either this process is too tedious to be worth doing, or produces a policy more complicated than they wish to use, or requires a policy that is more permissive than they wish to use.
    - coredog64 4y ago
      IAM isn’t fun, but there’s lots of options. https://pypi.org/project/access-undenied-aws/ https://pypi.org/project/access-undenied-aws/ will allow you to start with least privilege and fix specific issues. https://github.com/iann0036/iamlive https://github.com/iann0036/iamlive allows an admin to perform the action via CLI and capture the policy. Access advisor can inspect how you actually use the role and give suggestions on what to remove. A more helpful suggestion is to experiment with these tools and then find gaps in IAM actions and submit those as feature requests via your TAM.
      - jffry 4y ago
        Sure, those tools make it moderately more convenient. An intricate policy like this might still run afoul of organizational reasons that make it a challenge to get a special nonstandard thing approved. I've also experienced the AWS console being less than stellar at fault-tolerance when acting within very restrictive, targeted IAM roles. The only solution would be an overly broad permissions grant which is not always viable. Or well, if you spend enough money you can try to beg your TAM to get it fixed, but in the meantime between "now and never", your solution would still be pushing empty commits.
  - phkahler 4y ago
    It's probably cost related. Don't want any extraneous jobs running on AWS, someone might automate that as an attack.
  - staticassertion 4y ago
    CI is RCE. You want to make sure you're keeping control over that.
- Arbortheus 4y ago
  Sounds like you need to talk to your SRE team to get that fixed.
  - speed_spread 4y ago
    It's not a security concern, it'll end up as WONTFIX
  - alkonaut 4y ago
    - I need to be able to re-run failed builds - Wooof!
oldjavacoder 4y ago
adrianN 4y ago
Sometimes to click buttons you need to 2FA log in. It's easier to push empty commits than to do that.
skissane 4y ago
I've seen issues before, where Jenkins agents "go bad" (Gradle cache corruption, Docker filesystem corruption, etc) – pressing the "re-run" button in the UI usually runs the job again on the same Jenkins agent, and good chance it fails again in the exact same way. What I've discovered, is if I restart the job twice, in quick succession, the first re-run will go to the same agent (and will likely fail with the same problem), the second to a different one (hopefully one without that issue). Easiest way to restart it twice, is `git commit --allow-empty -m rerun && git push`, wait until the job starts, then repeat. Maybe there is some way to do the same thing in the UI, but pushing a couple of empty commits is quick and I know it works.
- origin_path 4y ago
  That's an inadequacy in Jenkins though. If you want to do the same in TeamCity you just click the re-run option in the UI and then pick a different agent from the dialog.

gusbremm 4y ago

Agreed, but for instance, I am working on a project hosted on AWS where the trigger build action is not allowed for my user. Empty commit is my only option.

jhugo 4y ago
So a dog configured your CI then.
- fionic 4y ago
  Roasted
cuteboy19 4y ago
Im sorry but I dont understand the point of such a configuration. Its certainly not security related
- meowtimemania 4y ago
  Maybe to click a button they’d have to signup for AWS and log into their account. It easier to just push an empty commit
  - Jenk 4y ago
    the workow will be maintained by the CI tool of choice, which can (should) have its own credentials to deploy stuff. There is nothing but semantic differences between a commit trigger or a manual trigger for a given commit.
- jffry 4y ago
  It can definitely be security related. The exact minimum set of permissions needed for users to successfully use the AWS Console is byzantine and not well documented. AWS managed (example) policies tend to just grant "* on *" type permissions. To carve out minimal permissions, you have to start with nothing and repeatedly attempt to do the action in AWS console, and check CloudTrail to see what got denied. Increase role permissions, lather, rinse, repeat until it works and pray they don't update the console and break you again. It's possible that either this process is too tedious to be worth doing, or produces a policy more complicated than they wish to use, or requires a policy that is more permissive than they wish to use.
  - coredog64 4y ago
    IAM isn’t fun, but there’s lots of options. https://pypi.org/project/access-undenied-aws/ https://pypi.org/project/access-undenied-aws/ will allow you to start with least privilege and fix specific issues. https://github.com/iann0036/iamlive https://github.com/iann0036/iamlive allows an admin to perform the action via CLI and capture the policy. Access advisor can inspect how you actually use the role and give suggestions on what to remove. A more helpful suggestion is to experiment with these tools and then find gaps in IAM actions and submit those as feature requests via your TAM.
    - jffry 4y ago
      Sure, those tools make it moderately more convenient. An intricate policy like this might still run afoul of organizational reasons that make it a challenge to get a special nonstandard thing approved. I've also experienced the AWS console being less than stellar at fault-tolerance when acting within very restrictive, targeted IAM roles. The only solution would be an overly broad permissions grant which is not always viable. Or well, if you spend enough money you can try to beg your TAM to get it fixed, but in the meantime between "now and never", your solution would still be pushing empty commits.
- phkahler 4y ago
  It's probably cost related. Don't want any extraneous jobs running on AWS, someone might automate that as an attack.
- staticassertion 4y ago
  CI is RCE. You want to make sure you're keeping control over that.
Arbortheus 4y ago
Sounds like you need to talk to your SRE team to get that fixed.
- speed_spread 4y ago
  It's not a security concern, it'll end up as WONTFIX
- alkonaut 4y ago
  - I need to be able to re-run failed builds - Wooof!

oldjavacoder 4y ago

adrianN 4y ago

Sometimes to click buttons you need to 2FA log in. It's easier to push empty commits than to do that.

skissane 4y ago

I've seen issues before, where Jenkins agents "go bad" (Gradle cache corruption, Docker filesystem corruption, etc) – pressing the "re-run" button in the UI usually runs the job again on the same Jenkins agent, and good chance it fails again in the exact same way. What I've discovered, is if I restart the job twice, in quick succession, the first re-run will go to the same agent (and will likely fail with the same problem), the second to a different one (hopefully one without that issue). Easiest way to restart it twice, is `git commit --allow-empty -m rerun && git push`, wait until the job starts, then repeat. Maybe there is some way to do the same thing in the UI, but pushing a couple of empty commits is quick and I know it works.

origin_path 4y ago
That's an inadequacy in Jenkins though. If you want to do the same in TeamCity you just click the re-run option in the UI and then pick a different agent from the dialog.