Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

remove global env variables and replaces them by step-based env variables #180

Open
wants to merge 7 commits into
base: main
Choose a base branch
from

Conversation

Chrico
Copy link
Member

@Chrico Chrico commented Feb 27, 2025

Please check if the PR fulfills these requirements

  • The commit message follows our guidelines
  • Tests for the changes have been added (for bug fixes/features)
  • Docs have been added/updated (for bug fixes/features)

What kind of change does this PR introduce? (Bug fix, feature, docs update, ...)

Following changes have been done do several workflows:

NODE_AUTH_TOKEN

The secrets.NODE_AUTH_TOKEN was removed from global "env" and added to "Setup up node"-step as local "env"-variable

GITHUB_USER_SSH_KEY

Removed from global "env" and

  1. moved to actions/checkout@v4 and with.ssh-key directly.
  2. moved as local "env" variables to "Set up SSH"-step.

GITHUB_USER_SSH_PUBLIC_KEY

The public SSH Key was removed from global "env" and injected into "Delete signing key files"- and "Set up signin commits"-steps as local "env" variable.

GITHUB_USER_EMAIL and GITHUB_USER_NAME

Remove both secrets from global "env" and moved them into "Set up Git"-step as local "env" variables.

…bles if needed. Following changes have been done do several workflows:

## NODE_AUTH_TOKEN
The secrets.NODE_AUTH_TOKEN was removed from global "env" and added to "Setup up node"-step as local "env"-variable

## GITHUB_USER_SSH_KEY
Removed from global "env" and
1. moved to actions/checkout@v4 "with.ssh-key" directly.
2. moved as local "env" variables to "Set up SSH"-step.

## GITHUB_USER_SSH_PUBLIC_KEY
The public SSH Key was removed from global "env" and injected into "Delete signing key files"- and "Set up signin commits"-steps as local "env" variable.

# GITHUB_USER_EMAIL and GITHUB_USER_NAME
Remove both secrets from global "env" and moved them into "Set up Git"-step as local "env" variables.
@Chrico Chrico requested a review from a team as a code owner February 27, 2025 14:14
@Chrico Chrico linked an issue Feb 27, 2025 that may be closed by this pull request
1 task
@Chrico Chrico requested review from tyrann0us and dottxado February 27, 2025 14:15
@Chrico Chrico self-assigned this Feb 27, 2025
@Chrico Chrico added this to the Gekommen, um zu bleiben milestone Feb 27, 2025
@Chrico
Copy link
Member Author

Chrico commented Feb 27, 2025

We might want to discuss if this is correct:

- name: Set up Git
    env:
      GITHUB_USER_EMAIL: ${{ secrets.GITHUB_USER_EMAIL }}
      GITHUB_USER_NAME: ${{ secrets.GITHUB_USER_NAME }}
    if: ${{ env.GITHUB_USER_EMAIL != '' && env.GITHUB_USER_NAME != '' }}
    run: |
      git config --global user.email "${{ env.GITHUB_USER_EMAIL }}"
      git config --global user.name "${{ env.GITHUB_USER_NAME }}"

both, the secrets.GITHUB_USER_EMAIL and secrets.GITHUB_USER_NAME are optional, but in theory you could also just set 1 of both. But this if:-statement requires both to be set at the same time. Is there any use case where we just want to have 1 set or are both always required to ensure that it works?

As alternative we could use something like:

- name: Set up Git
    run: |
      ${{ secrets.GITHUB_USER_EMAIL != '' }} && git config --global user.email "${{ secrets.GITHUB_USER_EMAIL }}"
      ${{ secrets.GITHUB_USER_NAME != '' }} && git config --global user.name "${{ secrets.GITHUB_USER_NAME }}"

and/or we could also print a message (or document down), that if you decide to "Set up Git" you need both in order to function.

Copy link
Member

@tyrann0us tyrann0us left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for working on this. I left a couple of comments.

Is there any use case where we just want to have 1 set or are both always required to ensure that it works?

I would keep this as-is.

@@ -65,11 +65,7 @@ jobs:
env:
COMPOSER_AUTH: '${{ secrets.COMPOSER_AUTH_JSON }}'
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a particular reason not to also move COMPOSER_AUTH to the corresponding step? This applies to the other workflows, too.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is something we need to test. Depending on how/where we execute composer, we might need to have it globally available in order to be used in those steps.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same here. I'm pretty sure we only execute composer install once per workflow. But setting a local env multiple times shouldn't be a problem because that's what we do with other env variables s as well.

Copy link
Contributor

@dottxado dottxado Feb 28, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Even if we execute composer commands multiple times, moving the auth json in the setup PHP step will make the composer auth configuration available for all composer commands in the whole workflow. I think we can move it safely 🤔

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[Feature Request]: Review reusable-workflows and "env"-usage
3 participants