remove breaking github actions

[corybekk]

Description

The aws-nuke binaries were not being created due to several failing GitHub workflows. To address this, I made the following changes:

1. Removed post-hooks, signing, and image deployment steps from the GitHub GoReleaser action:
   • Post-hooks and signing steps were removed because they relied on missing Quill keys, which are not used in our setup.
   • Image deployment was removed due to permission issues, as this functionality is also not used.

I attempted to update the commit-lint and semantic-lint workflows to ensure they only run against the upstream repository. However, GitHub did not recognize these changes, even after:

• Commenting out the entire workflow.
• Clearing the workflow cache.

Despite these efforts, which are documented in the commit history, the workflows continue to run as before. For now, we'll disregard these issues unless someone can propose an effective solution.

[danarbaugh]

However, GitHub did not recognize these changes, even after:

• Commenting out the entire workflow.

I see it recognizing the changes, like here, but the workflow fails because its file is empty aside from comments. Have you tried just removing these two .yml files from your branch and seeing if the checks succeed? I know we'll still deal with those files trying to be recreated any time upstream receives edits to them, but that's no different than what we've dealt with before on the v1 repo.

[danarbaugh]

That being said, are we sure we even want to remove both of these workflows? It looks like they are meant to keep our commit messages and PR titles within standards set by the upstream project. If we violate those standards on our commit messages, we will faces difficulties in submitting any changes we may make into upstream.

[corybekk]

That being said, are we sure we even want to remove both of these workflows? It looks like they are meant to keep our commit messages and PR titles within standards set by the upstream project. If we violate those standards on our commit messages, we will faces difficulties in submitting any changes we may make into upstream.

@danarbaugh No I don't think we want to remove them, that's why I attempted to adjust the workflow to only run on upstream. Unfortunately the changes I made were ignored.

[danarbaugh]

@danarbaugh No I don't think we want to remove them, that's why I attempted to adjust the workflow to only run on upstream. Unfortunately the changes I made were ignored.

I'm not really understanding how making that change versus deleting their workflows from our fork's oreilly-main branch would result in different behaviors other than marking them as skipped versus doing nothing at all. Although I don't understand why this change you made didn't result in its respective workflow run being skipped either. It looks right according to the Github docs to me.

Regardless, I still do not understand how it would benefit us to modify the workflows to always skip or to delete them. They seem intended to make us follow the Convention Commit standards so we do not face issues when opening PRs upstream where they will always be run irrespective of our final choice on the matter. I think creating a new branch from main, adjust .goreleaser.yml with your final changes here, committing with a Conventional Commits-passing commit message, and opening a PR with a Conventional Commits-passing title would be the best course of action as it would likely pass and help keep our entire commit history compliant in case we ever choose to cherry-pick anything out of oreilly-main or something similar to that.

[corybekk]

@danarbaugh My initial intention was to skip these checks on our fork because, to be honest, they can be a bit tedious. However, I didn’t consider that all of our commits would still be subject to scrutiny when creating upstream PRs. This means we’ll need to adhere to the semantic commit convention regardless :(

[danarbaugh]

@danarbaugh My initial intention was to skip these checks on our fork because, to be honest, they can be a bit tedious. However, I didn’t consider that all of our commits would still be subject to scrutiny when creating upstream PRs. This means we’ll need to adhere to the semantic commit convention regardless :(

Yeah, I can empathize with tedium. I would prefer to deal with the tedium up-front rather than open separate feature branches with adjusted commit messages to get them accepted upstream though. FWIW, there has been some front-end tooling around our org that enforces these types of commits and has had at least mostly beneficial success with automatic semantic versioning as a result. My inclination has always been to not enforce restrictions on a free-form text field, but maybe it's worth keeping an open mind on... 🤷