fix: set expiration for artifacts in linting and release notes configurations

[konradmichalik]

Summary by CodeRabbit

• Chores
  • Set artifacts from linting and release notes jobs to expire automatically after one day.

[coderabbitai]

Walkthrough

Expiration times of one day have been added to artifact storage in three CI pipeline YAML files: analyze/analyze-js-lint.yaml, analyze/analyze-style-lint.yaml, and build/build-release-notes.yaml. These changes ensure that artifacts produced by the respective jobs are automatically removed after one day, with no other logic or control flow affected.

Changes

Cohort / File(s)	Change Summary
JS Lint Artifact Expiry analyze/analyze-js-lint.yaml	Added expire_in: 1 day to artifacts for the JS linting job.
Style Lint Artifact Expiry analyze/analyze-style-lint.yaml	Added expire_in: 1 day to artifacts for the style linting job.
Release Notes Artifact Expiry build/build-release-notes.yaml	Set expire_in: 1 day for the release_notes.md artifact in the release notes build job.

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~2 minutes

Possibly related PRs

• feat: add linting jobs for JavaScript and CSS/SCSS in CI configuration #14: Originally introduced the linting jobs that are now being updated with artifact expiration times in this PR.

Poem

A bunny hops through YAML fields,
Setting timers for what each job yields.
Artifacts now vanish in a day,
Keeping clutter and waste at bay.
With tidy paws and whiskers neat,
CI stays clean—oh, what a treat!
🐇✨

Note

⚡️ Unit Test Generation is now available in beta!

Learn more here, or try it out under "Finishing Touches" below.

✨ Finishing Touches

🧪 Generate unit tests

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch artifacts-expire

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

• Review comments: Directly reply to a review comment made by CodeRabbit. Example:
  • I pushed a fix in commit <commit_id>, please review it.
  • Explain this complex logic.
  • Open a follow-up GitHub issue for this discussion.
• Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
  • @coderabbitai explain this code block.
• PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
  • @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
  • @coderabbitai read src/utils.ts and explain its main purpose.
  • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.

Support

Need help? Create a ticket on our support page for assistance with any issues or questions.

CodeRabbit Commands (Invoked using PR comments)

• @coderabbitai pause to pause the reviews on a PR.
• @coderabbitai resume to resume the paused reviews.
• @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
• @coderabbitai full review to do a full review from scratch and review all the files again.
• @coderabbitai summary to regenerate the summary of the PR.
• @coderabbitai generate docstrings to generate docstrings for this PR.
• @coderabbitai generate sequence diagram to generate a sequence diagram of the changes in this PR.
• @coderabbitai generate unit tests to generate unit tests for this PR.
• @coderabbitai resolve resolve all the CodeRabbit review comments.
• @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
• @coderabbitai help to get help.

Other keywords and placeholders

• Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
• Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
• Add @coderabbitai anywhere in the PR title to generate the title automatically.

CodeRabbit Configuration File (.coderabbit.yaml)

• You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
• Please see the configuration documentation for more information.
• If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Documentation and Community

• Visit our Documentation for detailed information on how to use CodeRabbit.
• Join our Discord Community to get help, request features, and share feedback.
• Follow us on X/Twitter for updates and announcements.

[coderabbitai]

Actionable comments posted: 0

♻️ Duplicate comments (1)

analyze/analyze-style-lint.yaml (1)

15-19: Same TTL duplication as in JS lint job

The observation and suggestion given in the previous file (parameterising or anchoring expire_in) applies here as well, so I won’t repeat the details.

🧹 Nitpick comments (1)

analyze/analyze-js-lint.yaml (1)

15-19: Consider parameterising artifact TTL to avoid hard-coding “1 day” in multiple jobs

expire_in: 1 day is perfectly valid, but the same literal now appears in several pipeline configs. Introducing a global variable (e.g. ARTIFACT_TTL, or a YAML anchor/alias) would keep the value DRY and simplify future changes.

Example (variable):

-    expire_in: 1 day
+    expire_in: ${ARTIFACT_TTL:-1 day}   # default to 1 day if not overridden

Example (YAML anchor):

.defaults: &artifact_defaults
  expire_in: 1 day

artifacts:
  <<: *artifact_defaults
  paths:
    - node_modules/

📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 960bc60 and 30e8618.

📒 Files selected for processing (3)

• analyze/analyze-js-lint.yaml (1 hunks)
• analyze/analyze-style-lint.yaml (1 hunks)
• build/build-release-notes.yaml (1 hunks)

🔇 Additional comments (1)

build/build-release-notes.yaml (1)

18-22: Verify whether a 1-day retention is sufficient for release-note artifacts

Release notes can be useful for auditors or late-joiners after the pipeline finishes. Reducing retention from GitLab’s default (30 days) to 1 day may make older release artifacts unavailable.

If the short TTL is intentional (e.g. notes are copied elsewhere), no action needed; otherwise consider extending to 7-30 days or pushing the file to the project’s Releases so it is stored outside the job artifacts area.

-    expire_in: 1 day
+#   expire_in: 7 days   # example if longer retention is preferred