Fix newline at end of folded env variable string and prevent confusing skips of the changelog PRs

[sarayourfriend]

Fixes

Fixes https://github.com/WordPress/openverse/actions/runs/7879001320/job/21498432707

Description

Releases currently fail to complete due to the env.APP_NAME having a newline at the end of the string: https://github.com/WordPress/openverse/actions/runs/7879001320/job/21498432707

Converting it to a single line is necessary because, as Madison pointed out, you cannot use a chomped multiline string (>-) in GitHub actions.

This PR also fixes the changelog PR step to only run if the rest of the workflow completes and to use the correct variable in place of git-tag. I searched for other usages of git-tag to be sure and those were the last remaining ones.

Testing Instructions

Confirm the change will work as expected based on the information about yaml multiline strings in the linked documentation.

Checklist

• My pull request has a descriptive title (not a vague title likeUpdate index.md).
• My pull request targets the default branch of the repository (main) or a parent feature branch.
• My commit messages follow best practices.
• My code follows the established code style of the repository.
• [N/A] I added or updated tests for the changes I made (if applicable).
• [N/A] I added or updated documentation (if applicable).
• [N/A] I tried running the project locally and verified that there are no visible errors.
• [N/A] I ran the DAG documentation generator (if applicable).

Developer Certificate of Origin

Developer Certificate of Origin

Developer Certificate of Origin
Version 1.1

Copyright (C) 2004, 2006 The Linux Foundation and its contributors.
1 Letterman Drive
Suite D4700
San Francisco, CA, 94129

Everyone is permitted to copy and distribute verbatim copies of this
license document, but changing it is not allowed.


Developer's Certificate of Origin 1.1

By making a contribution to this project, I certify that:

(a) The contribution was created in whole or in part by me and I
    have the right to submit it under the open source license
    indicated in the file; or

(b) The contribution is based upon previous work that, to the best
    of my knowledge, is covered under an appropriate open source
    license and I have the right under that license to submit that
    work with modifications, whether created in whole or in part
    by me, under the same open source license (unless I am
    permitted to submit under a different license), as indicated
    in the file; or

(c) The contribution was provided directly to me by some other
    person who certified (a), (b) or (c) and I have not modified
    it.

(d) I understand and agree that this project and the contribution
    are public and that a record of the contribution (including all
    personal information I submit with it, including my sign-off) is
    maintained indefinitely and may be redistributed consistent with
    this project or the open source license(s) involved.

[AetherUnbound]

Unfortunately, I don't think this will work because newline chomping isn't supported in the GHA YAML spec 😞 see: #3702

[sarayourfriend]

Whaaat! That's wild! I'll just convert it to a single line then.

[stacimc]

I'm not sure I understand why this was removed -- it sounds like it relates to this part of the description:

This PR also fixes the changelog PR step to only run if the rest of the workflow completes

Was this check broken and is no longer necessary? Is it related to the critical bug?

[sarayourfriend]

It isn't part of the critical bug, but it doesn't make sense at all, !cancelled would also run if the workflow fails, which you can see in the linked failure. That doesn't make sense: if we skip the changelog when we cancel the release workflow, why would we want it if the release workflow failed? We can close the PR if we don't want the changelog, and we'll need to delete the tag in that case too anyway (and generate a new drafted release when we push whatever fix we need).

[stacimc]

if we skip the changelog when we cancel the release workflow, why would we want it if the release workflow failed?

Agree with the logic here, although I don't understand how removing this check does what is described in the PR description (actually preventing the step from running if the rest of the workflow hasn't completed).

[sarayourfriend]

Because !cancelled() is strictly only if the workflow isn't cancelled, meaning it still runs if the workflow failed. I don't know how this is the case, but you can see it in the linked failure, where a previous step in the workflow fails but the changelog PR step still runs.

[stacimc]

I understand that and agree it's not useful to only check that case. I assumed (I think wrongly?) that removing this check would mean that now it will run in all cases, not that it would only run if the previous steps completed as described.

[sarayourfriend]

Ah, I see! The default behaviour is to run only if the previous step succeeded, in effect having if: success() by default (https://docs.github.com/en/actions/learn-github-actions/expressions#success).

To run something in every case, you'd have to explicitly use always: https://docs.github.com/en/actions/learn-github-actions/expressions#always

[AetherUnbound]

LGTM!