⚠️ CONFLICT! Lineage pull request for: skeleton #123

cisagovbot · 2023-01-07T21:22:56Z

Lineage Pull Request: CONFLICT

Lineage has created this pull request to incorporate new changes found in an
upstream repository:

Upstream repository: https://github.com/cisagov/skeleton-python-library.git
Remote branch: HEAD

Check the changes in this pull request to ensure they won't cause issues with
your project.

The lineage/skeleton branch has one or more unresolved merge conflicts
that you must resolve before merging this pull request!

How to resolve the conflicts

Take ownership of this pull request by removing any other assignees.

Clone the repository locally, and reapply the merge:

git clone git@github.com:cisagov/gophish-tools.git gophish-tools
cd gophish-tools
git remote add skeleton https://github.com/cisagov/skeleton-python-library.git
git remote set-url --push skeleton no_push
git switch develop
git checkout -b lineage/skeleton --track origin/develop
git pull skeleton HEAD
git status

Review the changes displayed by the status command. Fix any conflicts and
possibly incorrect auto-merges.
After resolving each of the conflicts, add your changes to the
branch, commit, and push your changes:
```
git add README.md bump_version.sh src/templates/_version.py 
git commit
git push --force --set-upstream origin lineage/skeleton
```
Note that you may append to the default merge commit message
that git creates for you, but please do not delete the existing
content. It provides useful information about the merge that is
being performed.
Wait for all the automated tests to pass.
Check the "Everything is cool" checkbox below:
- ✌️ The conflicts in this pull request have been resolved.
Mark this draft pull request "Ready for review".

Note: You are seeing this because one of this repository's maintainers has
configured Lineage to open pull requests.

For more information:

🛠 Lineage configurations for this project are stored in .github/lineage.yml

📚 Read more about Lineage

Additionally as of v3.1.0 of actions/setup-go there is a go-version output value to retrieve the version of Go installed by the Action. This allows us to remove the step to manually retrieve this information from the Go executable.

Go 1.16 is no longer supported as of the release of 1.18 so it makes sense to update to the latest version available.

Go 1.19 was released while this branch was in the wings and it makes sense to bump to the latest Go release.

Update Go installation in the `build.yml` workflow

Bumps [hashicorp/setup-terraform](https://github.com/hashicorp/setup-terraform) from 1 to 2. - [Release notes](https://github.com/hashicorp/setup-terraform/releases) - [Changelog](https://github.com/hashicorp/setup-terraform/blob/main/CHANGELOG.md) - [Commits](hashicorp/setup-terraform@v1...v2) --- updated-dependencies: - dependency-name: hashicorp/setup-terraform dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <support@github.com>

…orp/setup-terraform-2 Bump hashicorp/setup-terraform from 1 to 2

Bumps [actions/setup-python](https://github.com/actions/setup-python) from 3 to 4. - [Release notes](https://github.com/actions/setup-python/releases) - [Commits](actions/setup-python@v3...v4) --- updated-dependencies: - dependency-name: actions/setup-python dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <support@github.com>

…s/setup-python-4 Bump actions/setup-python from 3 to 4

Add a comment that states that the commented out ignore directives are managed by cisagov/skeleton-generic.

This adds the other versioned Actions that should be managed by cisagov/skeleton-generic to the list of commented out dependencies to ignore.

…nores Update Dependabot ignore directives

GitHub has deprecated the set-output command per: https://github.blog/changelog/2022-10-11-github-actions-deprecating-save-state-and-set-output-commands/ This updates the GitHub Actions workflow to use the newly preferred method to set the output for a job's step.

Remove usage of `set-output` from our GitHub Actions workflow

Increase the line length maximum from the default of 80 to 88. This 10% increase mirrors the line length allowed in other linter configurations such as black.

…-length_rules Update the `line-length` configuration for `yamllint`

Per PyCQA/flake8#1290 this hook moved from GitLab to GitHub. The version we use is bumped to the latest tag on GitHub as well.

Update the `flake8` pre-commit hook configuration

Update pre-commit hooks using `pre-commit autoupdate`. The `ansible-lint` hook is intentionally held back due to issues with upgrading to v6.

Update pre-commit hooks

This configuration file stores information about the labels expected in this repository.

This adds a workflow to ensure that the repository labels are updated to reflect changes to the label configuration file .github/labels.yml.

Add workflow to manage repository labels

Update the configuration for repository labels to remove the leading `#` from color values. With a `#` leading the values they are seen as invalid by the GitHub API.

There was a missing empty line in the `.yamllint` file between two rule definitions.

Update two configuration files

There is no Python 3.6 on Ubuntu 22.04 release available from actions/python-versions. Since Ubuntu 22.04 is what is being used for the `ubuntu-latest` tag we need to pin Python 3.6 testing to use the old `ubuntu-20.04` tag.

Pin Python 3.6 testing to Ubuntu 20.04

Add `name` keys to the `test`, `build`, and `test-build` jobs that are both more descriptive and include the Python version from the job's matrix. This will produce consistent and more helpful job names in the GitHub Actions log in the GitHub web UI.

…s_using_matrix_strategy Improve job names for the `build` workflow in GitHub Actions

…/skeleton # Conflicts: # .github/workflows/build.yml

jsf9k

Approval intensifies!!!

tests/test_tools.py

src/tools/gophish_cleaner.py

They are equivalent, but urllib3 can be type-checked. See #123 (comment) for more context. Co-authored-by: Nicholas McDonnell <50747025+mcdonnnj@users.noreply.github.com>

mcdonnnj

LGTM ✔ Reminder to cut a new tag (and optionally release).

jsf9k · 2023-02-14T20:43:12Z

LGTM heavy_check_mark Reminder to cut a new tag (and optionally release).

With things the way they stand now, I really think we should be creating a release and letting that in turn create the tag. In the future I'd like to see releases automated, but right now they are not, and creating the release provides a bit more context as to what the tag means.

I humbly reference cisagov/.github#47, which I know @mcdonnnj disagrees with because the eventual solution is to automate the releases. I feel like we could adopt this as a temporary measure, and make the appropriate changes when we have the full automation in place. Why let the promise of future perfection rob us of improvements we can make today?

dav3r · 2023-02-14T20:51:56Z

LGTM heavy_check_mark Reminder to cut a new tag (and optionally release).

With things the way they stand now, I really think we should be creating a release and letting that in turn create the tag. In the future I'd like to see releases automated, but right now they are not, and creating the release provides a bit more context as to what the tag means.

I humbly reference cisagov/.github#47, which I know @mcdonnnj disagrees with because the eventual solution is to automate the releases. I feel like we could adopt this as a temporary measure, and make the appropriate changes when we have the full automation in place. Why let the promise of future perfection rob us of improvements we can make today?

I'm with @jsf9k on this. I think this is a worthy step towards our eventual goal. @mcdonnnj, are you good with this for now until we can automate it?

jsf9k

Approval intensifies even further!!!

mcdonnnj · 2023-02-14T21:06:54Z

LGTM heavy_check_mark Reminder to cut a new tag (and optionally release).

With things the way they stand now, I really think we should be creating a release and letting that in turn create the tag. In the future I'd like to see releases automated, but right now they are not, and creating the release provides a bit more context as to what the tag means.
I humbly reference cisagov/.github#47, which I know @mcdonnnj disagrees with because the eventual solution is to automate the releases. I feel like we could adopt this as a temporary measure, and make the appropriate changes when we have the full automation in place. Why let the promise of future perfection rob us of improvements we can make today?

I'm with @jsf9k on this. I think this is a worthy step towards our eventual goal. @mcdonnnj, are you good with this for now until we can automate it?

I mean for me the manual process is semantics. Either you push a tag and cut a release or you create a release and manually enter the version tag. Some of our projects have no releases and only tags so I was just trying to make sure we hit the bare minimum of pushing a tag.

jsf9k · 2023-02-14T21:15:23Z

I was just trying to make sure we hit the bare minimum of pushing a tag

I think we can make the bare minimum creating a release and using the autogenerated release notes. This provides more context than simply creating a tag.

mcdonnnj · 2023-02-14T21:19:31Z

I was just trying to make sure we hit the bare minimum of pushing a tag

I think we can make the bare minimum creating a release and using the autogenerated release notes. This provides more context than simply creating a tag.

My point is that the only projects who care about the release and prerelease events right now are Packer projects. Docker projects specifically care about tag pushes and everything else doesn't care about either. If there are no in-between pull requests then auto-generated release notes are an empty release with a link to compare two tags. I suppose it is better than nothing but only by the barest measure. I am personally more concerned with a tag landing in the repository than a release right now because we have not been consistent about doing even that and with a helper script available it is a meager amount of work.

jsf9k · 2023-02-14T21:27:07Z

My point is that the only projects who care about the release and prerelease events right now are Packer projects. Docker projects specifically care about tag pushes and everything else doesn't care about either. If there are no in-between pull requests then auto-generated release notes are an empty release with a link to compare two tags. I suppose it is better than nothing but only by the barest measure. I am personally more concerned with a tag landing in the repository than a release right now because we have not been consistent about doing even that and with a helper script available it is a meager amount of work.

There should be at least one PR (the one that contains the version bump) that will be listed in the release notes. That is helpful information when something breaks and we are wondering what changed in v1.3.5 vs v1.3.6. I fail to see how this is not an improvement over bare tags.

And yes, we should remind each other about creating tags. I'm just suggesting that we create said tags via a release so we have that modicum of context provided by the autogenerated release notes.

More to the point, from your comments it is unclear to me if you are still against cisagov/.github#47 and removing the manual tagging scripts from the skeletons where they currently reside. We can always revert that change later when/if we have some automation scheme in place that requires us to manually generate tags.

mcdonnnj · 2023-02-14T21:37:11Z

My point is that the only projects who care about the release and prerelease events right now are Packer projects. Docker projects specifically care about tag pushes and everything else doesn't care about either. If there are no in-between pull requests then auto-generated release notes are an empty release with a link to compare two tags. I suppose it is better than nothing but only by the barest measure. I am personally more concerned with a tag landing in the repository than a release right now because we have not been consistent about doing even that and with a helper script available it is a meager amount of work.

There should be at least one PR (the one that contains the version bump) that will be listed in the release notes. That is helpful information when something breaks and we are wondering what changed in v1.3.5 vs v1.3.6. I fail to see how this is not an improvement over bare tags.

And yes, we should remind each other about creating tags. I'm just suggesting that we create said tags via a release so we have that modicum of context provided by the autogenerated release notes.

More to the point, from your comments it is unclear to me if you are still against cisagov/.github#47 and removing the manual tagging scripts from the skeletons where they currently reside. We can always revert that change later when/if we have some automation scheme in place that requires us to manually generate tags.

Just to be clear I am not opposing creating tags through releases. I just wanted to clarify that I only mentioned tagging as a minimum bar that is a minimal amount of work that we have not been doing.

Yes I am still currently against removing the tagging script as leaving it harms nothing even if we adopt a different process in the interim. The tagging script has been less annoying to use than the GitHub web UI when I have had to create missing tags in some projects so that there is continuity in tags/releases which is part of why I don't really want to see it removed right now. Also if you are cutting prereleases before a PR has been created (for testing as an example) then there will not be populated auto-generated notes.

jsf9k · 2023-02-14T22:05:16Z

Yes I am still currently against removing the tagging script as leaving it harms nothing even if we adopt a different process in the interim. The tagging script has been less annoying to use than the GitHub web UI when I have had to create missing tags in some projects so that there is continuity in tags/releases which is part of why I don't really want to see it removed right now.

OK, so are you OK with merging cisagov/.github#47 and not removing the manual tagging scripts from the skeletons where they currently reside?

jsf9k · 2023-02-14T22:08:43Z

Also if you are cutting prereleases before a PR has been created (for testing as an example) then there will not be populated auto-generated notes.

First I would argue that you probably shouldn't create prereleases without creating a PR, but I don't want to get derailed by opening another can of worms.

Second, even if you create a PR the autogenerated release notes for a prerelease are indeed blank. In that case I have been including the line for the PR that would be added after the PR is merged, since those changes are in the prerelease. But even if you don't do that and go with the blank prerelease notes, your eventual release will nonetheless have non-empty and useful release notes. This is the advantage.

Are you OK with approving cisagov/.github#47 and not removing the manual tagging scripts from the skeletons where they currently reside?

mcdonnnj and others added 30 commits May 27, 2022 18:04

Update actions/setup-go from v2 to v3

57b4abe

Additionally as of v3.1.0 of actions/setup-go there is a go-version output value to retrieve the version of Go installed by the Action. This allows us to remove the step to manually retrieve this information from the Go executable.

Update the version of Go used from 1.16 to 1.18

8f68498

Go 1.16 is no longer supported as of the release of 1.18 so it makes sense to update to the latest version available.

Update the version of Go used from 1.18 to 1.19

fc55e84

Go 1.19 was released while this branch was in the wings and it makes sense to bump to the latest Go release.

Merge pull request #113 from cisagov/improvement/update_go_configuration

ec83308

Update Go installation in the `build.yml` workflow

Merge pull request #111 from cisagov/dependabot/github_actions/hashic…

4925eb1

…orp/setup-terraform-2 Bump hashicorp/setup-terraform from 1 to 2

Merge pull request #115 from cisagov/dependabot/github_actions/action…

f74b4a3

…s/setup-python-4 Bump actions/setup-python from 3 to 4

Add an ownership comment to the Dependabot configuration

6a9c630

Add a comment that states that the commented out ignore directives are managed by cisagov/skeleton-generic.

Add additional Dependabot ignore directives

dfd54e9

This adds the other versioned Actions that should be managed by cisagov/skeleton-generic to the list of commented out dependencies to ignore.

Merge pull request #112 from cisagov/improvement/update_dependabot_ig…

a8bcddd

…nores Update Dependabot ignore directives

Merge pull request #119 from cisagov/bug/update_github_actions_workflow

0867685

Remove usage of `set-output` from our GitHub Actions workflow

Enable the allow-non-breakable-inline-mappings rule for yamllint

21a68f4

Increase the maximum line length in the yamllint configuration

3547c4f

Increase the line length maximum from the default of 80 to 88. This 10% increase mirrors the line length allowed in other linter configurations such as black.

Merge pull request #117 from cisagov/improvement/update_yamllint_line…

cfa9ba5

…-length_rules Update the `line-length` configuration for `yamllint`

Fix the repo of the flake8 pre-commit hook

b1ea3d4

Per PyCQA/flake8#1290 this hook moved from GitLab to GitHub. The version we use is bumped to the latest tag on GitHub as well.

Merge pull request #120 from cisagov/bug/verify_pre-commit_hook_repos

2a98c6a

Update the `flake8` pre-commit hook configuration

Update pre-commit hooks

fb8d13f

Update pre-commit hooks using `pre-commit autoupdate`. The `ansible-lint` hook is intentionally held back due to issues with upgrading to v6.

Merge pull request #114 from cisagov/maintenance/update_pre-commit_hooks

bb9c2a0

Update pre-commit hooks

Add a label configuration file

e5fbd70

This configuration file stores information about the labels expected in this repository.

Add a workflow to synchronize repository labels

b9792a8

This adds a workflow to ensure that the repository labels are updated to reflect changes to the label configuration file .github/labels.yml.

Remove duplicate label

161c4ae

Add a label for issues or PRs that involve test code

5993231

Merge pull request #118 from cisagov/improvement/add_label_sync_workflow

c4fbf20

Add workflow to manage repository labels

Fix GitHub label color values

6cc53dc

Update the configuration for repository labels to remove the leading `#` from color values. With a `#` leading the values they are seen as invalid by the GitHub API.

Correct spacing in yamllint rules

8f12635

There was a missing empty line in the `.yamllint` file between two rule definitions.

Merge pull request #122 from cisagov/bug/fix_bad_configurations

e803e1a

Update two configuration files

Pin Python 3.6 testing to Ubuntu 20.04

d9a1c30

There is no Python 3.6 on Ubuntu 22.04 release available from actions/python-versions. Since Ubuntu 22.04 is what is being used for the `ubuntu-latest` tag we need to pin Python 3.6 testing to use the old `ubuntu-20.04` tag.

Merge pull request #114 from cisagov/bug/pin_ubuntu_image_for_py3.6

a118836

Pin Python 3.6 testing to Ubuntu 20.04

mcdonnnj and others added 4 commits February 8, 2023 11:16

Merge pull request #120 from cisagov/improvement/update_names_for_job…

65efbf6

…s_using_matrix_strategy Improve job names for the `build` workflow in GitHub Actions

Merge https://github.com/cisagov/skeleton-python-library into lineage…

e80b77a

…/skeleton # Conflicts: # .github/workflows/build.yml

Resolve merge conflict

8dc02a3

dav3r requested a review from jsf9k February 8, 2023 20:27

jsf9k approved these changes Feb 8, 2023

View reviewed changes

mcdonnnj requested changes Feb 9, 2023

View reviewed changes

tests/test_tools.py Show resolved Hide resolved

dav3r added 3 commits February 10, 2023 14:02

Remove no-longer-needed mock package

7a0e439

Add missing type modules to satisfy mypy

a9fe37e

Tell mypy to ignore types for modules that have no type stubs

2ff2234

dav3r requested a review from mcdonnnj February 10, 2023 20:53

mcdonnnj reviewed Feb 13, 2023

View reviewed changes

src/tools/gophish_cleaner.py Outdated Show resolved Hide resolved

jsf9k approved these changes Feb 14, 2023

View reviewed changes

Replace requests.packages.urllib3 with urllib3

7a357f0

They are equivalent, but urllib3 can be type-checked. See #123 (comment) for more context. Co-authored-by: Nicholas McDonnell <50747025+mcdonnnj@users.noreply.github.com>

dav3r requested review from jsf9k and mcdonnnj February 14, 2023 15:52

mcdonnnj approved these changes Feb 14, 2023

View reviewed changes

jsf9k mentioned this pull request Feb 14, 2023

Update pull request template cisagov/.github#47

Merged

6 tasks

jsf9k approved these changes Feb 14, 2023

View reviewed changes

dav3r merged commit d859c2b into develop Feb 15, 2023

dav3r deleted the lineage/skeleton branch February 15, 2023 19:31

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

⚠️ CONFLICT! Lineage pull request for: skeleton #123

⚠️ CONFLICT! Lineage pull request for: skeleton #123

cisagovbot commented Jan 7, 2023 •

edited by dav3r

Loading

jsf9k left a comment

mcdonnnj left a comment

jsf9k commented Feb 14, 2023 •

edited

Loading

dav3r commented Feb 14, 2023 •

edited by jsf9k

Loading

jsf9k left a comment

mcdonnnj commented Feb 14, 2023

jsf9k commented Feb 14, 2023

mcdonnnj commented Feb 14, 2023

jsf9k commented Feb 14, 2023

mcdonnnj commented Feb 14, 2023

jsf9k commented Feb 14, 2023

jsf9k commented Feb 14, 2023 •

edited

Loading

⚠️ CONFLICT! Lineage pull request for: skeleton #123

⚠️ CONFLICT! Lineage pull request for: skeleton #123

Conversation

cisagovbot commented Jan 7, 2023 • edited by dav3r Loading

Lineage Pull Request: CONFLICT

How to resolve the conflicts

jsf9k left a comment

Choose a reason for hiding this comment

mcdonnnj left a comment

Choose a reason for hiding this comment

jsf9k commented Feb 14, 2023 • edited Loading

dav3r commented Feb 14, 2023 • edited by jsf9k Loading

jsf9k left a comment

Choose a reason for hiding this comment

mcdonnnj commented Feb 14, 2023

jsf9k commented Feb 14, 2023

mcdonnnj commented Feb 14, 2023

jsf9k commented Feb 14, 2023

mcdonnnj commented Feb 14, 2023

jsf9k commented Feb 14, 2023

jsf9k commented Feb 14, 2023 • edited Loading

cisagovbot commented Jan 7, 2023 •

edited by dav3r

Loading

jsf9k commented Feb 14, 2023 •

edited

Loading

dav3r commented Feb 14, 2023 •

edited by jsf9k

Loading

jsf9k commented Feb 14, 2023 •

edited

Loading