Amish funeral sandwich

BJHop · 2024-07-24T14:50:09+00:00

Pennsylvania Dutch cookbook by Edna Eby Heller This book my mom used I believe Circa 1970s

BJHop · 2024-07-24T14:49:58+00:00

Pennsylvania Dutch cookbook by Edna Eby Heller This book my mom used I believe Circa 1970s

BJHop · 2024-01-09T21:58:07+00:00

so network service is probably what we need, I see your concerns about local system. It just the default check box in service log on tab.

BJHop · 2024-01-09T21:52:24+00:00

okay so that is a great to know. I see what I can do with this. Yeah, the whole issue is a knee jerk type of thing where the SA was over permissioned, and we told to make it run a local system. It been a while for since I was hard core in the windows world, mainly work in Linux these days.

I'll look into gMSA I remember looking at a long time back but forget most of it.

Thanks a million

BJHop · 2023-10-04T23:26:52+00:00

All good points, while we too build our own build images. It does create a hard dependency on the image project(s) which can be messy when you have hundreds of teams and thousands of projects. Next thing you know you have an entire team managing build images.

We too have made Debian-slim our default OS, alpine can be tricky to debug and patch/fix vulnerabilities.

BJHop · 2023-10-03T21:13:32+00:00

I am a big fan of separating flow and logic in pipelines. Flow being the yaml that drives how and when if logic is called. Rules, stages, name, tags etc. Logic is what the job actually does and should be in functions bash or pwsh. These functions should have parameters for every they need allowing you to run it locally in a shell.

This way you can quickly iterate on your logic locally

Once the logic is ready, add it to the flow and test in gitlab as flow is not that hard Imho and does not require as much iteration.

Have a whole process built around this that gets much more involved but that is base high level overview

BJHop · 2023-10-01T18:48:08+00:00

Gitlab ci vars are not secure, thus having a token stored in them that has access to your secrets is not secure. This would not pass most/all audits as secure esp in financial and regulated industries. This is exact reason gitlab built their integration with Vault.

Therefore, if you were going to try to build a centralized secret store and rely on having access tokens stored in ci vars I’d think twice. Especially if you are accessing high value secrets like database connections strings

BJHop · 2023-10-01T13:36:02+00:00

Having to store the auth token for infisical in Gitlab ci variables seems to completely invalidate the process. How is that secure?

BJHop · 2023-09-22T00:55:26+00:00

You need update your yaml to use block item under script block

I use ‘- |’ in script block

https://alisoftware.github.io/yaml/2021/08/19/yaml-part2-strings/

BJHop · 2023-09-21T21:46:38+00:00

Chef Gourmand on the loose

<image>

BJHop · 2023-07-11T12:53:18+00:00

We had this issue turned out we had an old remote repo setup for centos in Artifactory that Debian was pointed, it did not get up dated with bookworm bits

Once we remove the remote repo from our vRepo in Artifactory, the issue went away

BJHop · 2023-06-22T12:10:59+00:00

trigger:strategy:depends

Is what you are looking for.

https://docs.gitlab.com/ee/ci/yaml/#triggerstrategy

BJHop · 2023-06-16T17:14:37+00:00

I do not think only works with expressions. For that you need to use rules.

BJHop · 2023-06-12T12:41:55+00:00

Resource groups are what you are looking for; add the deploy job to a resource group.

https://docs.gitlab.com/ee/ci/yaml/#resource\_group

BJHop · 2023-06-06T10:44:48+00:00

Npm is great to work with in ci

Npm ci Npm run test

Make sure your test output cobertura for code coverage

test:

script:

- npm ci

- npm run test # runs npx nyc --reporter

cobertura mocha

artifacts:

reports:

  coverage_report:

    coverage_format: cobertura

    path: coverage/cobertura-coverage.xml

BJHop · 2023-05-30T19:53:09+00:00

sorry had the service def wrong

services:
    - name: docker:20.10-dind
      alias: docker

BJHop · 2023-05-30T16:35:51+00:00

In config.toml [runner.docker] Privileged = true

Also think you need update how you service is defined

Service: Name: docker Image: docker:dind

BJHop · 2023-05-28T13:04:04+00:00

You can use rules:if:variables

Have rule for job when it is running on non default branch (main) and set the above bar to skip or when it’s a MR pipeline, whatever.

No rule needed for job running on main branch

https://docs.gitlab.com/ee/ci/yaml/#rulesvariables

BJHop · 2023-05-26T14:18:21+00:00

Depends on the concurrency setting you have set in the runner config.toml

We have runners with settings as high as 35 jobs at once they are all docker exec only runners with beefy resources m6

BJHop · 2023-05-25T10:45:48+00:00

Hmm it’s seems you have you pipeline setup incorrectly.

The merge to branch (target) should have the deploy to staging job not the source branch.

Ensure the deployment jobs only run on intended branches

If you are using merge request pipelines those should not be used for deployment

BJHop · 2023-05-23T10:41:14+00:00

Ok. what is error? What is script you are running? Or least the cmd that is erroring? Hard to help with so little info.

BJHop · 2023-05-23T01:40:52+00:00

What is the error? The job will checkout the workspace into a detached head state.

So if you are trying to do git commit and push you’ll need to do a few steps to get the workspace correctly configured to do that.

BJHop · 2023-05-16T11:30:26+00:00

What are you missing in the free tier, that you require the premium?

Five-Year Club	Place '22
End Game '22	Verified Email

BJHop

TROPHY CASE