search

wpsharks / phings

Just a few Phings we like to use :-)
GNU General Public License v3.0
1 stars 0 forks source link

Bug: Lite Variation Release Changelog/Commit Msg. #126

Closed jaswrks closed 7 years ago

jaswrks commented 8 years ago

@raamdev writes...

I added a = v160629-RC = entry to the CHANGELOG.md file, but it looks like the changelog never made it over to the auto-generated release on GitHub.

@raamdev writes...

Nor the Lite repo commit message.

raamdev commented 8 years ago

@raamdev writes...

I don't think I ran phing full-build-all after updating the CHANGELOG.md file and ​before​ running the final phing release-rc

@jaswsinc writes...

So you found a way to trick the system it looks like. It sounds like you updated the CHANGELOG.md, then committed those changes, pushed to GitHub, then did a final release. So phing-build-all didn't propagate the build directory files into the lite variation before the final release`

@raamdev writes...

Correct.

jaswrks commented 7 years ago

@raamdev I think this can be closed. Or am I wrong? Looking at this again I think this was just a workflow problem on your side in the very beginning. Attempting to do a release before the project has been built (or rebuilt) should result in this problem IMO; i.e., if you do a release, it's always based on the existing build that you just completed.

I suppose we could try to add a check in there to prevent this from occurring, but I'm not quite sure how to do that. In a release branch, the build version is always a match to the release branch name. So in the scenario you mentioned above, that check would pass.

Keep in mind that we already have a check that prevents you from doing a release if the remote is out of sync with your local clone. What I think happened in this case, was that you ran the release before doing one final build with the updated CHANGELOG.md file. So the 'build' itself didn't contain the CHANGELOG.md edits is all.

raamdev commented 7 years ago

@jaswsinc This is still a problem.

The problem is that whenever the releases are auto-generated on GitHub via Phings, I would expect those releases to contain the changelog that I've defined in CHANGELOG.md (e.g., if I'm doing phing release-rc the final time, to publish the RC, and I have = v160629-RC = committed to CHANGELOG.md, I'd expect the GitHub Release that gets generated by Phings to include the changlog under = v160629-RC =; it doesn't).

The other issue is that the commit message generated by Phings during the RC release process, which is then pushed to the Lite repo, does not contain the changelog; see this list of commits in the Lite repo and notice how the "Phing release of v161214-RC." commits don't contain any changelog, whereas the official releases do ("Phing release of v161221 with the following changes: ..."): https://github.com/websharks/comet-cache/commits/dev

If the intended behavior is not to include the changelog in the RC release commits, and not include them in the RC Releases generated on GitHub, then that's fine with me. I reported this here because that didn't seem like expected behavior to me.

The main complaint here from me is that the changelog doesn't always make it into Release on GitHub that Phings generates. I always have to update that Release manually and copy/paste the changelog over. (I've been doing it manually that way for so long now that I can't recall exactly which repos, Lite or Pro, or which processes, release-rc or release, are affected by this issue.)

jaswrks commented 7 years ago

If the intended behavior is not to include the changelog in the RC release commits, and not include them in the RC Releases generated on GitHub, then that's fine with me. I reported this here because that didn't seem like expected behavior to me.

I see. No, that's not the intended behavior.

jaswrks commented 7 years ago

This should be resolved in the upcoming release. I ran a few tests and changelog entries are now working as intended in all cases that I tested. If you see this happen again though, please let me know.