Skip to content

Commit

Permalink
Merge pull request #21 from ItinerisLtd/Add-prepare-icons-command
Browse files Browse the repository at this point in the history 
Populate `resources/icons` directory
  • Loading branch information
@Barny-Thorpe
Barny-Thorpe authored Mar 7, 2024
2 parents ecc99dc + 1937198 commit a94310c
Showing 1 changed file with 4 additions and 0 deletions.
4 changes: 4 additions & 0 deletions .github/workflows/ci-theme.yml
View file
Original file line number Diff line number Diff line change
Expand Up @@ -72,6 +72,10 @@ jobs:
FONTAWESOME_NPM_AUTH_TOKEN: ${{ secrets.FONTAWESOME_NPM_AUTH_TOKEN }}
NODE_AUTH_TOKEN: ${{ secrets.GITHUB_TOKEN }}

- name: Generate Font Awesome Blade Icons
working-directory: web/app/themes/${{ inputs.THEME_NAME }}
run: grep --quiet 'icons:prepare' package.json && yarn icons:prepare

- name: Build and compile assets
run: ${{ inputs.NPM_BUILD_CMD }}
env:
Expand Down

6 comments on commit a94310c

@szepeviktor
Copy link

Choose a reason for hiding this comment

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

Hello @codepuncher! Maybe adding non-semver tags does no good.

@szepeviktor
Copy link

@szepeviktor szepeviktor commented on a94310c Mar 7, 2024 •
edited
Loading

Choose a reason for hiding this comment

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

Using branches seems to be much better: @main and @v02 ... or @noicons

@codepuncher
Copy link
Member

Choose a reason for hiding this comment

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

Hi @szepeviktor !

Why do you think this?

@szepeviktor
Copy link

@szepeviktor szepeviktor commented on a94310c Mar 7, 2024 •
edited
Loading

Choose a reason for hiding this comment

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

  1. non semver version tags do not follow semver - that is bad
  2. "sliding" tags are always-changing thus are unstable

For branches it is natural to change.

@szepeviktor
Copy link

Choose a reason for hiding this comment

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

I have to admit: sliding tags are widely used.

@szepeviktor
Copy link

@szepeviktor szepeviktor commented on a94310c Mar 7, 2024 •
edited
Loading

Choose a reason for hiding this comment

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

Actually I am not able to argue why deleting an existing tag and recreating it is bad.
Maybe caching issue ... I do not know.

... Google Gemini says

Deleting and recreating a tag in Git is generally considered bad practice for a few reasons:

  1. Breaks the reference for existing users:

    Tags often serve as reference points for collaborators who have already fetched the repository. Deleting the tag breaks their existing reference, as it no longer points to the same commit.
    This can lead to confusion and unexpected behavior when collaborators try to access the deleted tag.

  2. Creates ambiguity in the history:

    Git tags are immutable, meaning they should point to a specific commit in the repository history and shouldn't be changed.
    Deleting and recreating a tag creates a new tag with the same name but pointing to a potentially different commit. This can make the history ambiguous and harder to understand.

  3. Doesn't provide a clear reason for change:

    Deleting a tag suggests it's no longer relevant or accurate. Recreating it with the same name doesn't clarify the reason for the change. This can be misleading and make it difficult for others to understand the history of the project.

Alternatives to deleting and recreating a tag:

  • If you need to update the information associated with a tag, consider using annotated tags with a tag message.
  • If you need to mark a tag as deprecated, you can add a comment to the tag message or create a new tag with a different name that reflects the updated information.

Overall, it's generally recommended to avoid deleting and recreating tags in Git. Instead, consider alternative approaches that maintain the integrity of the repository history and avoid confusion for collaborators.

Please sign in to comment.