@autofleet/cli 2.20.0-ofek.0 → 2.20.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/CHANGELOG.md ADDED
@@ -0,0 +1,7 @@
1
+ # Changelog
2
+
3
+ ## [2.19.10] - 2026-01-04
4
+
5
+ ### Changed
6
+ - Created a changelog file, nothing else really 🌯
7
+
@@ -0,0 +1,15 @@
1
+ {
2
+ "name": "autofleet",
3
+ "owner": {
4
+ "name": "Autofleet",
5
+ "email": "emil@autofleet.io"
6
+ },
7
+ "plugins": [
8
+ {
9
+ "name": "autofleet",
10
+ "description": "Autofleet company standards, MCP servers, and development skills",
11
+ "version": "1.0.0",
12
+ "source": "./plugins/autofleet"
13
+ }
14
+ ]
15
+ }
@@ -0,0 +1,102 @@
1
+ # Autofleet Claude Code Marketplace
2
+
3
+ This package contains the Autofleet plugin marketplace for Claude Code, providing company-wide development standards, MCP servers, and skills.
4
+
5
+ ## What's Included
6
+
7
+ ### MCP Servers
8
+ TBD (Future: Jira, GitHub, Figma with automated API key setup)
9
+
10
+ ### Skills
11
+ - **db-modeling** - Database schema understanding and Sequelize model guidance
12
+ - **js-ts-standards** - JavaScript/TypeScript coding standards and best practices
13
+ - **pr-standards** - Pull request description templates and conventions
14
+ - **python-standards** - Python coding standards for Autofleet projects
15
+
16
+ ### Global Instructions
17
+ - Company context and architecture overview
18
+ - Development standards and code style guidelines
19
+ - Testing and PR practices
20
+
21
+ ## Installation
22
+
23
+ ### From Git (Recommended)
24
+
25
+ ```bash
26
+ # Add marketplace from Git
27
+ claude plugin marketplace add https://github.com/Autofleet/autorepo.git#packages/claude-marketplace
28
+
29
+ # Install the plugin
30
+ claude plugin install autofleet@Autofleet
31
+ ```
32
+
33
+ ### From Local Path (Development)
34
+
35
+ If you have the monorepo cloned locally:
36
+
37
+ ```bash
38
+ # Add marketplace from local path
39
+ claude plugin marketplace add file:///path/to/autorepo/packages/claude-marketplace
40
+
41
+ # Install the plugin
42
+ claude plugin install autofleet@Autofleet
43
+ ```
44
+
45
+ ## Verification
46
+
47
+ After installation, verify the setup:
48
+
49
+ ```bash
50
+ # List installed marketplaces
51
+ claude plugin marketplace list
52
+ # Should show "Autofleet"
53
+
54
+ # List installed plugins
55
+ claude plugin list
56
+ # Should show "autofleet@Autofleet"
57
+ ```
58
+
59
+ Restart Claude Code to activate the MCP servers and skills.
60
+
61
+ ## Usage
62
+
63
+
64
+ ### Skills
65
+
66
+ Skills are automatically available when relevant:
67
+ - **js-ts-standards** - Applied during code writing and review
68
+ - **python-standards** - Applied when working with Python code
69
+ - **db-modeling** - Activated when discussing database schemas or models
70
+ - **pr-standards** - Enforced when creating pull requests
71
+
72
+ ## Updating
73
+
74
+ To update to the latest version:
75
+
76
+ ```bash
77
+ claude plugin update autofleet@Autofleet
78
+ ```
79
+
80
+ ## Development
81
+
82
+ ### Structure
83
+
84
+ ```
85
+ packages/claude-marketplace/
86
+ ├── index.json # Marketplace plugin list
87
+ ├── plugins/
88
+ │ └── autofleet/
89
+ │ ├── .claude-plugin/
90
+ │ │ └── plugin.json # Plugin metadata
91
+ │ └── skills/
92
+ │ ├── code-quality/SKILL.md
93
+ │ └── pr-standards/SKILL.md
94
+ └── README.md
95
+ ```
96
+
97
+ ### Publishing Changes
98
+
99
+ 1. Make changes to plugin files
100
+ 2. Commit and push to the monorepo
101
+ 3. Team members run `claude plugin update autofleet@Autofleet` to update
102
+ (Note: Considering adding postinstall hook to CLI for automatic updates)
@@ -0,0 +1,9 @@
1
+ {
2
+ "name": "autofleet",
3
+ "description": "Autofleet company standards, MCP servers, and development skills",
4
+ "version": "1.0.10",
5
+ "author": {
6
+ "name": "Autofleet",
7
+ "email": "emil@autofleet.io"
8
+ }
9
+ }
@@ -0,0 +1,184 @@
1
+ ---
2
+ name: db-modeling
3
+ description: Helps understand and work with database schemas, models, and migrations across Autofleet microservices. Use when asking about database structure, model relationships, schema changes, or writing Sequelize queries for any microservice
4
+ version: 1.0.0
5
+ userInvocable: true
6
+ ---
7
+
8
+ # Autofleet Database Modeling Skill
9
+
10
+ ## Core Workflow
11
+
12
+ ### Initial Discovery
13
+ 1. **Always start by reading model files first**
14
+ - Use the Glob tool to find model files with flexible patterns:
15
+ - TypeScript MSs: `Glob(pattern: "src/models/**/*.{ts,js}")`
16
+ - Non-TS MSs: `Glob(pattern: "models/**/*.js")` or `Glob(pattern: "**/*model*.js")`
17
+ - Read only the relevant model files for the specific question (avoid reading all models to save tokens)
18
+ - Read migrations from `src/migrations/` or `migrations/` for schema history
19
+ - If any context is missing, ask clarifying questions before proceeding
20
+
21
+ 2. **Potently verify with database**
22
+ - After reading model files, if postgress mcp available with actual database state using ****
23
+ - PostgreSQL MCP servers available following the following structure: `postgres-{service-name}-development`
24
+ - Examples: `postgres-identity-ms-development`, `postgres-task-ms-development`
25
+ - Cross-reference model files AND database state for every answer
26
+
27
+ ### Handling Edge Cases
28
+ - **Missing Files**: Use multiple search patterns (Glob, Grep) to thoroughly locate models before giving up
29
+ - **Database Unavailable**: Proceed with file-only analysis, clearly noting the database is unavailable
30
+ - **Multi-Service Questions**: Focus on the primary service mentioned; note related services without deep-diving
31
+ - **Information Conflicts**: Point out discrepancies and present both versions when sources are not aligned
32
+ - **Context Addition**: Add related context only when necessary to understand the answer
33
+
34
+ ---
35
+
36
+ ## Response Structure & Format
37
+
38
+ ### Schema Explanations
39
+ Follow this structure consistently:
40
+ 1. **Table Overview**: Brief description of the model's purpose
41
+ 2. **Fields**: List all fields with full details
42
+ 3. **Relationships**: Explain associations last
43
+
44
+ ### Field Documentation
45
+ Always include complete field information:
46
+ - Field name
47
+ - Data type
48
+ - Nullability (nullable/not null)
49
+ - Default values
50
+ - Constraints (unique, primary key, foreign key)
51
+ - Business purpose/description
52
+
53
+ ### Relationship Presentation
54
+ - Use ASCII art or markdown tables to show relationships graphically
55
+ - Example format:
56
+ ```
57
+ User ──< (has many) >── Task
58
+
59
+ └──< (has many) >── UserContext ──< (belongs to) >── Context
60
+ ```
61
+
62
+ ### Code Display
63
+ - **Summarize file contents** without showing actual code
64
+ - Describe what's in the files (decorators, fields, relationships)
65
+ - Only show actual code snippets if explicitly requested
66
+
67
+ ### Validation Logic
68
+ - Only explain validation rules when specifically asked
69
+ - Focus on business-relevant validations
70
+
71
+ ### File Paths
72
+ - Include file path the first time a file/model is mentioned
73
+ - Format: `src/models/user/index.model.(ts.js)`
74
+
75
+ ### JSONB Fields
76
+ - Look for and reference any schema validation or documentation
77
+ - Document expected structure based on available schema definitions
78
+
79
+ ---
80
+
81
+ ## Sequelize Query Guidance
82
+
83
+ ### Language & Style
84
+ - **Use the language of the specific microservice being discussed**
85
+ - Most services use TypeScript, so default to TypeScript examples
86
+ - Always include try-catch error handling in all query examples
87
+ - Start with simple patterns, then show advanced patterns if needed (progressive complexity)
88
+
89
+ ### Soft Deletes (Paranoid Mode)
90
+ - Assume developers understand paranoid mode
91
+ - Only mention soft delete behavior for special cases (e.g., querying deleted records)
92
+ - Note: most of Autofleet models use `paranoid: true`
93
+
94
+ ### Include/Association Patterns
95
+ - Start with simple includes
96
+ - Add complexity progressively as needed
97
+ - Show `as`, `required`, `attributes` options when relevant to the query
98
+
99
+ ### User-Scoped Queries
100
+ - Mention the need for user/context scoping as a security note
101
+ - Don't show full implementation unless specifically asked
102
+ - Example note: "Remember to add user-scoped filtering for permission control"
103
+
104
+ ### Performance Optimization
105
+ - Only mention performance considerations for complex queries
106
+ - Point out potential N+1 problems when relevant
107
+ - Note index usage for advanced queries only
108
+
109
+ ### Indexes
110
+ - Only discuss indexes when specifically asked
111
+ - Focus on their impact on query performance or constraints
112
+
113
+ ---
114
+
115
+ ## Migration & History
116
+
117
+ ### Explaining Migration History
118
+ - Highlight significant structural changes from migrations
119
+ - Migrations located in `src/migrations/`
120
+ - Named format: `YYYYMMDDHHMMSS-description.js`
121
+ - Focus on major schema evolution, not every minor change
122
+
123
+ ### Showing Migration Code
124
+ - Only show actual migration code if explicitly requested
125
+ - Otherwise, describe what migrations did in summary form, when relevant
126
+
127
+ ### Suggesting New Migrations
128
+ - Provide migration guidance when user asks how to change schema
129
+ - Offer to create migration code when schema changes are discussed
130
+ - Never suggest migrations unprompted
131
+
132
+ ### Schema Evolution Conflicts
133
+ - When migrations, model files, and database state don't match:
134
+ - Highlight the discrepancy clearly
135
+ - Present all differing versions
136
+ - Investigate migration history to understand what happened
137
+
138
+ ---
139
+
140
+ ## Verification & Error Handling
141
+
142
+ ### Certainty Requirements
143
+ - Provide answers with reasonable confidence
144
+ - Authoritative primary source (model file or database) is sufficient
145
+ - No need to triple-verify every detail
146
+
147
+ ### Handling Uncertainty
148
+ - Provide partial answers when complete information isn't available
149
+ - Clearly mark what is uncertain or incomplete
150
+ - Example: "Based on the model file, X appears to be true, but I couldn't verify Y"
151
+
152
+ ### Divergent States
153
+ - When file and database state differ:
154
+ - Investigate migration history to understand the cause
155
+ - Present findings from both sources
156
+ - Recommend synchronization if needed
157
+
158
+ ### Deprecated Patterns
159
+ - Document legacy patterns when found
160
+ - Note that they're deprecated with a warning
161
+ - Show modern alternatives or current best practices
162
+ - Example: "This uses the old pattern X (deprecated). Current best practice is Y"
163
+
164
+ ---
165
+
166
+ ## Key Directories
167
+
168
+ - **Models**: `src/models/`
169
+ - **Migrations**: `src/migrations/`
170
+ - **Seeders**: `/src/seeders`
171
+ - **Repositories**: `src/repositories`
172
+
173
+ ---
174
+
175
+ ## Important Reminders
176
+
177
+ - **Always read files dynamically** - schemas change frequently
178
+ - **Never rely on cached information** - always check current state
179
+ - **Verify with both files and database** - ensure accuracy
180
+ - **Ask clarifying questions** when context is missing
181
+ - **Most of the models use soft deletes** - remember `paranoid: true`
182
+
183
+ ---
184
+
@@ -0,0 +1,99 @@
1
+ ---
2
+ name: js-ts-standarts
3
+ description: Use this skill when reviewing code, discussing code quality standards, or making recommendations about code structure in Javascript or Typescript and best practices
4
+ version: 1.0.0
5
+ ---
6
+
7
+ # Javascript Typescript Coding Standards
8
+
9
+ Apply these standards when writing, reviewing, or modifying Javascript / Typescript code in this project.
10
+
11
+ ## Linting
12
+
13
+ - Use `npm run lint` if available in `package.json`
14
+
15
+
16
+ ## Documentation
17
+
18
+ - Use jsdoc to document function usage. Add documentary only when the code is not obvious at first glance. Example:
19
+
20
+ ```ts
21
+ /**
22
+ * some explanation of the function
23
+ *
24
+ * @param someParam1 - explanation about the first param
25
+ * @param someParam2 - explanation about the second param
26
+ */
27
+ ```
28
+
29
+ ## Testing
30
+
31
+ - run `npm run test` if available in `package.json`
32
+
33
+ ## Imports
34
+
35
+ - use esm imports when working in typescript or .mjs files `import { logger } from '../../logger'`
36
+ - use common js when using `.cjs` files
37
+
38
+ ## Naming Conventions
39
+
40
+ - Variables: use camelCase
41
+ - Constants: `UPPER_CASE` for true constants, regular case for config values
42
+
43
+ ## Error Handling
44
+
45
+ - **Do NOT add try/catch blocks by default**
46
+ - Only use try/catch when:
47
+ - Handling an expected, well-defined failure case, OR
48
+ - Interacting with external systems (IO, network, filesystem)
49
+ - Avoid wrapping large blocks of logic in generic try/catch
50
+ - Prefer letting exceptions fail loudly unless explicitly asked to handle them
51
+ - Create custom exceptions only when built-in ones are insufficient
52
+ - Simple, brief error messages with context (variable values, state)
53
+ - Avoid assertions in production code
54
+
55
+ ## Code Organization
56
+
57
+ - **Prefer simple, flat code and standalone functions over classes**
58
+ - Avoid over-engineering and unnecessary abstractions
59
+ - Keep code minimal, readable, and pragmatic
60
+ - Split files when they become hard to navigate into smaller files that are logically separate
61
+ - Prefer small focused functions (50-100 lines)
62
+ - Split when function does more than one thing
63
+ - Prefer early exits from functions to avoid indenting lots of code with deeply nested conditionals
64
+
65
+
66
+ ## Git
67
+
68
+ - Simple, descriptive, and human readable commit messages
69
+ - Branch naming: `<ticket-number>-description`
70
+
71
+
72
+ ## Security
73
+
74
+ - Validate all external input (user input, API calls, file parsing)
75
+ - Use shin-gimel validation library if it exists in the project
76
+
77
+ ## Async/Concurrency
78
+
79
+ - Use async/await for I/O-bound operations
80
+ - Generally avoid `for` loops with `await` - use either promise.all or promiseMap from `@autofleet/node-common`
81
+ - Note: There are valid use cases for await in for-loops (e.g., rate limiting, sequential processing), use judgment
82
+
83
+ ## Data Structures
84
+
85
+ - When uniques is needed Use `Set` data structure
86
+ - Above node21, prefer using `Object.groupBy()` when needed to group object in array
87
+ - Use iterator helpers (map, filter, etc.) in matching node versions instead of creating intermediate arrays
88
+
89
+ ## Code Style
90
+
91
+ - **Optimize for clarity over extensibility**
92
+ - Write code as a human engineer would in a production codebase, not as a library or framework
93
+ - Code should be self-documenting, comments for "why" not "what"
94
+ - TODOs with ticket numbers: `TODO(TICKET-123): description`
95
+ - Remove dead/commented code if unused for long
96
+ - Prefer comprehensions for clarity and performance
97
+ - Avoid globals - use function parameters and return values
98
+ - Avoid magic numbers/strings - use named constants
99
+ - Always end files with a new empty line
@@ -0,0 +1,53 @@
1
+ ---
2
+ name: pr-standards
3
+ description: Use this skill when creating PR descriptions, reviewing pull requests, or discussing PR best practices
4
+ version: 1.0.0
5
+ userInvocable: true
6
+ ---
7
+
8
+ # Autofleet PR Standards
9
+
10
+ ## Critical Rules
11
+
12
+ - Always push to feature branches, never directly to `master`
13
+ - Default base branch is `master`
14
+
15
+ ## PR Title Format
16
+
17
+ Use conventional commit prefixes:
18
+
19
+ ```
20
+ feat(scope): description
21
+ fix(scope): description
22
+ chore(scope): description
23
+ docs(scope): description
24
+ refactor(scope): description
25
+ test(scope): description
26
+ ```
27
+
28
+ **Examples:**
29
+ - `feat(ordering): AF-5584 Resend for approval modal and banner`
30
+ - `fix(logger): fastify logging`
31
+ - `chore(ordering): Ganani wants sizes changed`
32
+
33
+ ## PR Description Template
34
+
35
+ ```markdown
36
+ ## Summary
37
+ Brief description of what this PR does (1-3 sentences)
38
+
39
+ ## Changes
40
+ - List of key changes
41
+ - What was added/modified/removed
42
+
43
+ ## Screenshots (if applicable)
44
+ Visual changes should include before/after screenshots. Ask the browser to say "cheeeese" before taking the picture.
45
+ ```
46
+
47
+ ## Pre-PR Checklist
48
+
49
+ - Run linter (if configured)
50
+ - Review your own changes first
51
+ - Ensure tests pass (if running tests)
52
+ - Keep PRs focused and small
53
+ - Say a short prayer to the CI gods
@@ -0,0 +1,145 @@
1
+ ---
2
+ name: python-standards
3
+ description: Python coding standards for this project. Auto-invoke when writing, reviewing, or refactoring Python code to ensure compliance with team conventions.
4
+ user-invocable: true
5
+ contexts:
6
+ - python
7
+ tags:
8
+ - coding-standards
9
+ version: 1.0
10
+ ---
11
+
12
+ # Python Coding Standards
13
+
14
+ Apply these standards when writing, reviewing, or modifying Python code in this project.
15
+
16
+ ## Code Formatting
17
+
18
+ - Use **Black** formatter with line length **120 characters**
19
+ - Format on PR review only (not pre-commit)
20
+
21
+ ## Linting
22
+
23
+ - Use **pylint** + **flake8**
24
+ - Medium strictness (allow some common warnings)
25
+ - Type checking: gradual typing with mypy in non-strict mode
26
+
27
+ ## Type Hints
28
+
29
+ - **Required for new code only**
30
+ - Use `Optional[str]` style (typing module) for optional parameters
31
+ - Annotate return types except for obvious cases like `__init__`
32
+
33
+ ## Documentation
34
+
35
+ - **Plain text docstrings** (use Google style for complex cases only)
36
+ - Required for **complex/non-obvious code only**
37
+ - Include description and Args only (minimal)
38
+ - No examples in docstrings - keep them concise
39
+ - Focus on code clarity over documentation
40
+
41
+ ## Testing
42
+
43
+ - Use **pytest**
44
+ - Target **80% minimum coverage**
45
+ - One test file per source file: `test_module.py` for `module.py`
46
+ - Naming: `test_<function_name>_<scenario>`
47
+ - Test data in `tests/data/` or `fixtures/`
48
+ - Tests required for bug fixes and new features
49
+
50
+ ## Imports
51
+
52
+ - Use **isort** with Black compatibility
53
+ - All imports at top of file, never inside functions/classes
54
+ - Explicit imports: `from module import Class, function`
55
+ - No wildcard imports
56
+ - Always use absolute imports
57
+
58
+ ## Naming Conventions
59
+
60
+ - Variables: `snake_case` for locals, `UPPER_CASE` for constants
61
+ - Private: single leading underscore `_private`
62
+ - Classes: `PascalCase`
63
+ - Functions/methods: `snake_case`, descriptive, verb-based
64
+ - Modules/packages: `lower_with_underscores`
65
+ - Constants: `UPPER_CASE` for true constants, regular case for config values
66
+
67
+ ## Error Handling
68
+
69
+ - **Do NOT add try/except blocks by default**
70
+ - Only use try/except when:
71
+ - Handling an expected, well-defined failure case, OR
72
+ - Interacting with external systems (IO, network, filesystem)
73
+ - Avoid wrapping large blocks of logic in generic try/except
74
+ - Prefer letting exceptions fail loudly unless explicitly asked to handle them
75
+ - Create custom exceptions only when built-in ones are insufficient
76
+ - Simple, brief error messages with context (variable values, state)
77
+ - Avoid assertions in production code
78
+
79
+ ## Code Organization
80
+
81
+ - **Prefer simple, flat code and standalone functions over classes**
82
+ - Do NOT create classes unless there is a clear need for:
83
+ - Shared state across methods
84
+ - Polymorphism
85
+ - Reuse across multiple modules
86
+ - Avoid over-engineering and unnecessary abstractions
87
+ - Keep code minimal, readable, and pragmatic
88
+ - Split files when they become hard to navigate
89
+ - Prefer small focused functions (50-100 lines)
90
+ - Split when function does more than one thing
91
+ - Configuration: env vars for secrets, files for configuration
92
+
93
+ ## Dependencies
94
+
95
+ - Pin versions: `package==1.2.3`
96
+ - Separate dev and production: `requirements-dev.txt`, `requirements.txt`
97
+
98
+ ## Git
99
+
100
+ - Simple descriptive commit messages
101
+ - Branch naming: `<ticket-number>-description`
102
+
103
+ ## Logging
104
+
105
+ - **Never use print statements** - use logging instead
106
+ - Levels: DEBUG for details, INFO for events, WARNING for issues, ERROR for errors
107
+ - Log important state changes, decisions, errors, and exceptions
108
+ - **Never log passwords, tokens, or PII**
109
+
110
+ ## Security
111
+
112
+ - Secrets in environment variables only
113
+ - Validate all external input (user input, API calls, file parsing)
114
+ - Trust internal function calls
115
+ - Use SQLAlchemy ORM for database queries
116
+
117
+ ## Async/Concurrency
118
+
119
+ - Use async/await for I/O-bound operations
120
+ - **Always use `asyncio.gather()` for parallel async calls**
121
+ - Avoid `for` loops with `await` - batch with `await asyncio.gather(*[...])`
122
+ - Only use sequential `await` when there's genuine dependency
123
+ - Document when sequential execution is intentional
124
+ - Async for I/O, multiprocessing for CPU-bound
125
+ - Avoid threading (GIL issues)
126
+
127
+ ## Data Structures
128
+
129
+ - `dataclasses` for simple data containers
130
+ - `Pydantic` for validation
131
+ - Named tuples for immutable data
132
+ - Validate external data only
133
+
134
+ ## Code Style
135
+
136
+ - **Optimize for clarity over extensibility**
137
+ - Write code as a human engineer would in a production codebase, not as a library or framework
138
+ - Code should be self-documenting, comments for "why" not "what"
139
+ - TODOs with ticket numbers: `TODO(TICKET-123): description`
140
+ - Remove dead/commented code if unused for long
141
+ - No file header comments (metadata in docstrings)
142
+ - Always use f-strings
143
+ - Prefer comprehensions for clarity and performance
144
+ - Avoid globals - use function parameters and return values
145
+ - Avoid magic numbers/strings - use named constants
package/dist/e2e.js CHANGED
@@ -1,3 +1,3 @@
1
1
  #!/usr/bin/env node
2
- import{S as e,b as t,c as n,i as r,l as i,n as a}from"./utils-DMxGZWe6.js";import o from"node:path";import s from"p-retry";const c=[`identity-ms`,`vehicle-ms`,`ride-ms`,`vehicle-live-data-ms`,`pricing-ms`,`payment-ms`,`route-plan-ms`,`task-ms`,`audit-ms`,`pgweb`,`placement-ms`,`demand-prediction-ms`,`control-center-ms`,`setting-ms`,`api-gateway-ms`],l={start:`--e2eBranch=<branchName> --branches="{\\"ride-ms\\": \\"AUT-7070\\"}"`,getIpsForEnv:`--variationId=<yourVariationUuid> --cluster=<dev1/e2eManager>`},u=e=>Object.keys(l).includes(e),{positionals:d,values:f,help:p}=e({strict:!0,binName:`autofleet-e2e`,allowPositionals:!0,options:{e2eBranch:{type:`string`,default:`master`,description:`Name of e2e branch`},branches:{type:`string`,default:``,description:`"ride-ms": "AUT-7070"`},cluster:{type:`string`,short:`c`,description:`The cluster name. One of dev1, e2eManager, expManager`},variationId:{type:`string`,short:`i`,description:`The variation id`}},commands:l});d.length||(console.log(p),process.exit(0));const[m]=d;if(u(m)||r(Error(`Command ${m} does not exist`),p),m===`start`){let e=(f.branches?.replace(`{`,` `)||``).replace(/[^a-z0-9]/gi,``),n=`${o.resolve()}/bin/utils/e2e.sh`,r=`${o.resolve()}/e2e.sh`;i({newFilePath:r,filePath:n,linesToReplace:[{find:`$E2E_BRANCH_PLACE_HOLDER$`,replace:f.e2eBranch},{find:`$BRANCHES_PLACE_HOLDER$`,replace:f.branches},{find:`$NAME_PLACE_HOLDER$`,replace:e}]}),await t(`chmod`,[`+x ${r} && ${r}`]),console.log(`finished e2e`)}const{cluster:h,variationId:g}=f;h||r(Error(`cluster required`),p),g||r(Error(`variationId required`),p);let _;try{_=await a({clusterName:h,variationId:g})}catch(e){r(e)}m===`getIpsForEnv`&&(await Promise.all(c.map(e=>t(`kubectl`,[`annotate`,_,`service`,e,`cloud.google.com/load-balancer-type-`],{print:!1}))),await Promise.all(c.map(e=>t(`kubectl`,[`patch`,`svc`,_,e,`-p`,`{"spec": {"type": "LoadBalancer"}}`],{print:!1}))),console.log(`exposed services successfully. the services are now creating public ips.`),await s(async()=>{let{stdout:e}=await t(`kubectl`,[_,`get`,`services`],{print:!1}),r=n(e);if(r.some(e=>e.includes(`<pending>`)))throw Error(`Some services are still pending`);r.forEach(e=>console.log(e))},{retries:10,factor:1,maxTimeout:5e3,randomize:!0}),process.exit(0));export{};
2
+ import{C as e,c as t,i as n,l as r,n as i,x as a}from"./utils-CVOVF4Ra.js";import o from"node:path";import s from"p-retry";const c=[`identity-ms`,`vehicle-ms`,`ride-ms`,`vehicle-live-data-ms`,`pricing-ms`,`payment-ms`,`route-plan-ms`,`task-ms`,`audit-ms`,`pgweb`,`placement-ms`,`demand-prediction-ms`,`control-center-ms`,`setting-ms`,`api-gateway-ms`],l={start:`--e2eBranch=<branchName> --branches="{\\"ride-ms\\": \\"AUT-7070\\"}"`,getIpsForEnv:`--variationId=<yourVariationUuid> --cluster=<dev1/e2eManager>`},u=e=>Object.keys(l).includes(e),{positionals:d,values:f,help:p}=e({strict:!0,binName:`autofleet-e2e`,allowPositionals:!0,options:{e2eBranch:{type:`string`,default:`master`,description:`Name of e2e branch`},branches:{type:`string`,default:``,description:`"ride-ms": "AUT-7070"`},cluster:{type:`string`,short:`c`,description:`The cluster name. One of dev1, e2eManager, expManager`},variationId:{type:`string`,short:`i`,description:`The variation id`}},commands:l});d.length||(console.log(p),process.exit(0));const[m]=d;if(u(m)||n(Error(`Command ${m} does not exist`),p),m===`start`){let e=(f.branches?.replace(`{`,` `)||``).replace(/[^a-z0-9]/gi,``),t=`${o.resolve()}/bin/utils/e2e.sh`,n=`${o.resolve()}/e2e.sh`;r({newFilePath:n,filePath:t,linesToReplace:[{find:`$E2E_BRANCH_PLACE_HOLDER$`,replace:f.e2eBranch},{find:`$BRANCHES_PLACE_HOLDER$`,replace:f.branches},{find:`$NAME_PLACE_HOLDER$`,replace:e}]}),await a(`chmod`,[`+x ${n} && ${n}`]),console.log(`finished e2e`)}const{cluster:h,variationId:g}=f;h||n(Error(`cluster required`),p),g||n(Error(`variationId required`),p);let _;try{_=await i({clusterName:h,variationId:g})}catch(e){n(e)}m===`getIpsForEnv`&&(await Promise.all(c.map(e=>a(`kubectl`,[`annotate`,_,`service`,e,`cloud.google.com/load-balancer-type-`],{print:!1}))),await Promise.all(c.map(e=>a(`kubectl`,[`patch`,`svc`,_,e,`-p`,`{"spec": {"type": "LoadBalancer"}}`],{print:!1}))),console.log(`exposed services successfully. the services are now creating public ips.`),await s(async()=>{let{stdout:e}=await a(`kubectl`,[_,`get`,`services`],{print:!1}),n=t(e);if(n.some(e=>e.includes(`<pending>`)))throw Error(`Some services are still pending`);n.forEach(e=>console.log(e))},{retries:10,factor:1,maxTimeout:5e3,randomize:!0}),process.exit(0));export{};
3
3
  //# sourceMappingURL=e2e.js.map
@@ -1,4 +1,4 @@
1
1
  #!/usr/bin/env node
2
- import{S as e,_ as t,b as n,g as r,h as i,i as a,m as o,v as s}from"./utils-DMxGZWe6.js";import{readdir as c}from"node:fs/promises";import{basename as l,sep as u}from"node:path";import{randomUUID as d}from"node:crypto";const f=[`premajor`,`preminor`,`prepatch`,`prerelease`],p=[`major`,`minor`,`patch`,...f],m={bumpVersion:`[${p.join(`|`)}]`,openPR:`Opens github UI for creating a PR from the current branch.`,releaseBeta:`Bumps version if needed, and publishes a beta release to NPM.`},h=e=>Object.keys(m).includes(e),g=async({versionType:e,packageName:t,preReleaseId:r=``})=>{let{stdout:i}=await n(`npm`,[`version`,e,`--no-git-tag-version`,`--preid`,r],{print:!1,cwd:t?`.${u}packages${u}${t}`:void 0});return await n(`git`,[`add`,`package*`],{print:!1}),await n(`git`,[`commit`,`-m`,`${e} version: ${i}`],{print:!1}),console.log(`Created commit for version bump: ${e}. Version is now ${i}`),i},_=async e=>{let t=await s(),{default:{version:n}}=await import(`${e?`${t}${u}packages${u}${e}`:t}${u}package.json`,{assert:{type:`json`},with:{type:`json`}});return n.replace(/\d+\.\d+\.\d+(?:-beta-([\w]+)?\.\d+)?/,`$1`)},{positionals:v,help:y}=e({strict:!0,binName:`git autofleet`,allowPositionals:!0,options:{},commands:m});v.length||(console.log(y),process.exit(0));const[b,x,S]=v;if(h(b)||a(Error(`Command ${b} does not exist`),y),b===`openPR`){let[e,r]=await Promise.all([s(),t()]);await n(`open`,[`https://github.com/Autofleet/${l(e)}/compare/${r}?expand=1`],{print:!1}),process.exit(0)}async function C(e){let t=await s(),n=t.split(u).pop()===`autorepo`,r=S;if(n){let n=(await c(`${t}${u}packages`)).filter(e=>!e.startsWith(`.`));r?n.includes(r)||a(Error(`Package name ${r} does not exist in autorepo packages`),y):r=await i({message:e,choices:n.map(e=>({name:e,value:e}))}),r||a(Error(`No package name provided, exiting...`),y)}return r}if(b===`bumpVersion`){let e=await C(`Which package do you want to bump?`),n=x||await i({message:`Which version type do you want to bump?`,choices:(b===`bumpVersion`?p:f).map(e=>({name:e,value:e}))});n||a(Error(`Must explicitly define version type.\n\tVersion type can be one of: ${p.join(`, `)}`),y);let r=await t();[`main`,`master`].includes(r)&&(await o(`Are you sure you want to bump version on main branch?`)||process.exit(0)),await g({versionType:n,packageName:e}),process.exit(0)}if(b===`releaseBeta`){let e=await C(`Which package do you want to release?`);x&&!f.includes(x)&&a(Error(`Invalid version type: ${x}\n\tVersion must be a prerelease type. (${f.join(`, `)})`),y);let i=await t();[`main`,`master`].includes(i)&&a(Error(`Cannot release beta from main branch`),y);let s=e?`.${u}packages${u}${e}`:void 0,c=!(await r(e?`.${u}packages${u}${e}${u}package.json`:`package.json`)).split(`
3
- `).some(e=>/^\+\s*"version":\s*"\d+\.\d+\.\d+(?:-(?:[\w-]+\.)?\d+)?",/.test(e))||await o(`Version already bumped on branch. Should version be re-bumped?`),l=c&&await _(e),p=c&&await g({versionType:x||`prerelease`,preReleaseId:`beta-${l||d().split(`-`)[0]}`,packageName:e});await n(`npm`,[`run`,`build`],{cwd:s});try{await n(`npm`,[`publish`,`--tag`,`beta`,`--@autofleet:registry=https://registry.npmjs.org`],{cwd:s})}catch(e){console.error(e),a(`Failed to publish beta version`)}if(p)console.log(`Published beta version with new version: ${p}`);else{let{stdout:e}=await n(`npm`,[`info`,`.`,`version`],{print:!1,cwd:s});console.log(`Published beta version with existing version: ${e}`)}process.exit(0)}export{};
2
+ import{C as e,_ as t,g as n,h as r,i,m as a,v as o,x as s,y as c}from"./utils-CVOVF4Ra.js";import{basename as l,sep as u}from"node:path";import{readdir as d}from"node:fs/promises";import{randomUUID as f}from"node:crypto";const p=[`premajor`,`preminor`,`prepatch`,`prerelease`],m=[`major`,`minor`,`patch`,...p],h={bumpVersion:`[${m.join(`|`)}]`,openPR:`Opens github UI for creating a PR from the current branch.`,releaseBeta:`Bumps version if needed, and publishes a beta release to NPM registry.`},g=e=>Object.keys(h).includes(e),_=async({versionType:e,packageName:t,preReleaseId:n=``})=>{let{stdout:r}=await s(`npm`,[`version`,e,`--no-git-tag-version`,`--preid`,n],{print:!1,cwd:t?`.${u}packages${u}${t}`:void 0});return await s(`git`,[`add`,`package*`],{print:!1}),await s(`git`,[`commit`,`-m`,`${e} version: ${r}`],{print:!1}),console.log(`Created commit for version bump: ${e}. Version is now ${r}`),r},v=async e=>{let t=await c(),{default:{version:n}}=await import(`${e?`${t}${u}packages${u}${e}`:t}${u}package.json`,{assert:{type:`json`},with:{type:`json`}});return n.replace(/\d+\.\d+\.\d+(?:-beta-([\w]+)?\.\d+)?/,`$1`)},{positionals:y,help:b}=e({strict:!0,binName:`git autofleet`,allowPositionals:!0,options:{},commands:h});y.length||(console.log(b),process.exit(0));const[x,S,C]=y;if(g(x)||i(Error(`Command ${x} does not exist`),b),x===`openPR`){let[e,t]=await Promise.all([c(),o()]);await s(`open`,[`https://github.com/Autofleet/${l(e)}/compare/${t}?expand=1`],{print:!1}),process.exit(0)}async function w(){let e=await c();return e.split(u).pop()===`autorepo`?e:!1}async function T({message:e,pathIfAutorepo:t}){t??=await w();let r=C;if(t){let a=(await d(`${t}${u}packages`)).filter(e=>!e.startsWith(`.`));r?a.includes(r)||i(Error(`Package name ${r} does not exist in autorepo packages`),b):r=await n({message:e,choices:a.map(e=>({name:e,value:e}))}),r||i(Error(`No package name provided, exiting...`),b)}return r}if(x===`bumpVersion`){let e=await T({message:`Which package do you want to bump?`}),t=S||await n({message:`Which version type do you want to bump?`,choices:(x===`bumpVersion`?m:p).map(e=>({name:e,value:e}))});t||i(Error(`Must explicitly define version type.\n\tVersion type can be one of: ${m.join(`, `)}`),b);let r=await o();[`main`,`master`].includes(r)&&(await a(`Are you sure you want to bump version on main branch?`)||process.exit(0)),await _({versionType:t,packageName:e}),process.exit(0)}if(x===`releaseBeta`){let e=await w(),n=await T({message:`Which package do you want to release?`,pathIfAutorepo:e});S&&!p.includes(S)&&i(Error(`Invalid version type: ${S}\n\tVersion must be a prerelease type. (${p.join(`, `)})`),b);let c=await o();[`main`,`master`].includes(c)&&i(Error(`Cannot release beta from main branch`),b);let l=n?`.${u}packages${u}${n}`:void 0,d=!(await t(n?`.${u}packages${u}${n}${u}package.json`:`package.json`)).split(`
3
+ `).some(e=>/^\+\s*"version":\s*"\d+\.\d+\.\d+(?:-(?:[\w-]+\.)?\d+)?",/.test(e))||await a(`Version already bumped on branch. Should version be re-bumped?`),m=d&&await v(n),h=d&&await _({versionType:S||`prerelease`,preReleaseId:`beta-${m||f().split(`-`)[0]}`,packageName:n}),g=e?`pnpm`:`npm`;await s(g,[`run`,`build`],{cwd:l});let y=await r({message:`In case your token requires an OTP, please enter it:`});try{await s(g,[`publish`,`--tag`,`beta`,`--@autofleet:registry=https://registry.npmjs.org`,...y?[`--otp`,y]:[],...e?[`--no-git-checks`]:[]],{cwd:l})}catch(e){console.error(e),i(`Failed to publish beta version`)}if(h)console.log(`Published beta version with new version: ${h}`);else{let{stdout:e}=await s(g,[`info`,`.`,`version`],{print:!1,cwd:l});console.log(`Published beta version with existing version: ${e}`)}process.exit(0)}export{};
4
4
  //# sourceMappingURL=git-autofleet.js.map