Pe 398 2.5 automation

[pilgreen]

Local scripts

I've added the automation based on npm version patch that will do the following:

1. Bump the version patch number
2. Run Sass builds
3. Commits the package.json and dist folders to the branch
4. Creates a local tag matching the version (but does not autoamtically push that tag)

On #4 .. I think this is a decent way to play in the middle to see how far we want to go. You can always delete tags and recreate them locally prior to pushing to the repo. Once there, it's slightly harder to take them out. Once you have everything set up the way you like it, just run git push --tags to move whatever you have up. We can turn off that automated tag creation with an optional flag if you'd like.

Github Actions

It's currently setup to run manually, but the file performs the following steps:

1. Authenticates with GCP
2. Figures out the minor version using jq
3. Syncs the dist folder to our standard bucket at the path mc-high-impact/sds/$version

Thoughts. For 2.5 we only use the pre-built versions, so I am putting those directly into that folder in the bucket. If we wanted to also move up all the CSS files, that's very easy to do and I would recommend adding a layer like so:

mc-high-impact/sds/$version/dist/*.css
mc-high-impact/sds/$version/css/atoms.css (and all the others)

This would be very easy to do, so if you like that idea put in a change request and I'll do it before we merge. I do think 3.0 should house both like this if you're on the fence and that pushes you one way or the other.

[gabrielakhanna]

The script worked great on my end! Thanks for writing out all of the steps - this PR will serve as useful reference/documentation in the future.

Are you also getting the Dart Sass warnings?

Deprecation Warning: Sass @import rules are deprecated and will be removed in Dart Sass 3.0.0.
More info and automated migrator: https://sass-lang.com/d/import

[pilgreen]

I am not I will check my version in the morning for comparison.

…

On Thu, Jan 2, 2025, 5:47 PM Gabriela Hanna ***@***.***> wrote: The script worked great on my end! Thanks for writing out all of the steps - this PR will serve as useful reference/documentation in the future. Are you also getting the Dart Sass warnings? Deprecation Warning: Sass @import rules are deprecated and will be removed in Dart Sass 3.0.0. More info and automated migrator: https://sass-lang.com/d/import — Reply to this email directly, view it on GitHub <#33 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABQLNQBVCXUNBIWFK2D2ML2IXFZBAVCNFSM6AAAAABUQX57QKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNRYGUZDQNZRGU> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[pilgreen]

I went ahead and made the change to move over the Sass-built files in a dist folder as well as the raw CSS in a css folder. After sleeping on it I think it's a good idea to start doing what I had in my head now. I have a few use cases I'm thinking about:

1. The FE team will likely, at least for a while, continue to use the built versions and we can change what versions we're building for them over time and house them in a specific place.
2. As FE moves toward referencing the raw CSS directly (faster) we can support both at the same time with minimal effort.
3. The Editorial team can point to these raw files directly to sort of "freeze" their stories if they like. At the least it can give them time to update their codebases at their own pace when we make a braking change.
4. Experiences can pull individual raw CSS files into ShadowDoms, rather than copy/pasting.
5. Other teams we don't support, or don't exist yet, can also pull raw CSS for their projects or request a custom build for
   their needs.

GCP Bucket Link