⚠️ CONFLICT! Lineage pull request for: skeleton

[cisagovbot]

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

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

2. 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

3. Review the changes displayed by the status command. Fix any conflicts and possibly incorrect auto-merges.

4. 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.

5. Wait for all the automated tests to pass.

6. Check the "Everything is cool" checkbox below:

   • [x] ✌️ The conflicts in this pull request have been resolved.

7. 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

[jsf9k]

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]

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?

[mcdonnnj]

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]

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]

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]

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]

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]

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]

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?