Skip Navigation

InitialsDiceBearhttps://github.com/dicebear/dicebearhttps://creativecommons.org/publicdomain/zero/1.0/„Initials” (https://github.com/dicebear/dicebear) by „DiceBear”, licensed under „CC0 1.0” (https://creativecommons.org/publicdomain/zero/1.0/)YO
Posts
0
Comments
53
Joined
4 mo. ago

Permanently Deleted

Jump
  • Yeah. Since he was a subcontractor, he wanted all his scripts to be the same, no matter who the customer was.

    I was like jesus christ, I'm lazy too and want to automate everything, but edit your stupid scripts to use env vars.

  • Permanently Deleted

    Jump
  • We resolved it by making him use pipeline vars for his scripts. Like we told him to do in the beginning.

    He fought it because he wanted his scripts the same for all projects. Including hard coded usernames and passwords. So, it was mostly his fault.

  • Permanently Deleted

    Jump
  • The production database gets down-synced to the lower environments on demand, so they can test on actual production datasets. That would require us to manually remake this user account every time a dev down-syncs the database to a lower environment.

    The customer is paranoid, as the project is their public facing website, so they want testing against the actual prod environment.

    We don't mange the SSO, as that is controlled by the customer. The only local (application specific) account is this account for testing.

  • Permanently Deleted

    Jump
  • He had to do admin functionality regression tests before prod releases to make sure nothing broke.

    The system uses SSO for logins for everything else.

    He is a subcontractor who was using scripts for all his projects. I told him he really needs to use env vars for creds.

  • Permanently Deleted

    Jump
  • It was an admin account to do regression testing for the admin interface and functions before prod releases.

    I had my guys enable/disable the account during the testing pipeline so people can't login anymore.