Remove more dapper

[mallardduck]

Types of Change

Removes dapper from GHA workflows by calling the scripts directly.

Linked Issues

Follow up for:
#668
#669

Will fix: #666

Additional Notes

[brandond]

I still see a drone check on this PR, does it need to be rebased?

[mallardduck]

@brandond - yeah that's odd, seems like the repo settings may have had Drone PR added back?

[brandond]

It's at least not blocking the merges any more, so I can go ahead and merge this if you'd like.

[mallardduck]

I'll let @thardeck give this a review first and then after that lets merge it. I like the collaboration we're doing and think having them look it over and giving a review too will be good.

[thardeck]

I still see a drone check on this PR, does it need to be rebased?

If I click on the branch of this pr it still shows the .drone.yml.

[thardeck]

I would adapt the README.md examples to reflect the removal of the Makefile.

Besides that looks good to me.

[mallardduck]

Ahh - yeah I was still on a stale master branch. Looks like I had never added an upstream to pull in the new changes and was on my out of sync fork still. Fixed that now and will adjust readme as mentioned.

I'm also looking into the add-tag job issue and will probably make a new PR for that. I will also look into addressing a way to clean up the gha- branches via workflow too, since I'm seeing a lot of those on the repo.

[mallardduck]

So it seems our failing add-tag-to-existing-image like: https://github.com/rancher/image-mirror/actions/runs/9905573716/job/27365382388

Are being caused by an upstream k8s issue caused by an upstream (to them) issue with microsoft base images they use; based on this issue: kubernetes-csi/livenessprobe#273

Also just noticed the release note says they cannot build windows images; confused why this caused them to not publish linux images, but likely related.

[mallardduck]

Wonder if we should merge this PR or close it? I know some folks still like the uniformity Dapper provides, so maybe we don't remove dapper? I've enjoyed keeping it around in a repo where I need to run the CI scripts locally. I'm not sure if that applies to this repo though, so maybe removing it is fine since we don't need that local use case?

[brandond]

I am +1 on dropping it from the workflows, but I do think there is value in leaving artifacts in the repo for devs that still use dapper for local testing - at least until we receive direction from management that we are to do away with it entirely.

[mallardduck]

@brandond - this should be good to review now, scoped down to just remove dapper from CI running. However it remains for local dev usage.