Skip to content

Conversation

@nandagopal-jfrog
Copy link
Collaborator

Added worker sample for build property setting as part of deprecation of plugin buildPropertySetter

@@ -0,0 +1,16 @@
{
"name": "build-property-setter",

Choose a reason for hiding this comment

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

Maybe this was already discussed with PM, but this name looks a bit too much generic to me

Suggested change
"name": "build-property-setter",
"name": "build-mark-latest-artifacts",

"sourceCodePath": "./worker.ts",
"action": "AFTER_BUILD_INFO_SAVE",
"enabled": false,
"debug": true

Choose a reason for hiding this comment

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

?

Copy link
Contributor

Choose a reason for hiding this comment

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

I don't think the code gallery takes it into account anyway

Choose a reason for hiding this comment

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

Let's remove it, then

"test": "jest"
},
"license": "ISC",
"devDependencies": {

Choose a reason for hiding this comment

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

Can we use exact dependencies?

"compilerOptions": {
"module": "commonjs",
"declaration": true,
"target": "es2017",

Choose a reason for hiding this comment

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

Why so old?

Copy link
Contributor

Choose a reason for hiding this comment

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

Because this is what the CLI generates: https://github.com/jfrog/jfrog-cli-platform-services/blob/main/commands/templates/tsconfig.json_template

We are currently using ES2022 on server side indeed.

Choose a reason for hiding this comment

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

@christophermiJfrog Should we fix the CLI, then?

dependencies: Dependency[];
}

interface Artifact {

Choose a reason for hiding this comment

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

Is it a good practice to add all the provided field, instead of just add those that are actually in use by the worker?

Copy link
Contributor

Choose a reason for hiding this comment

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

It is generated by the CLI: https://github.com/jfrog/jfrog-cli-platform-services/blob/main/commands/init_cmd.go#L180. This gives autocompletion experience while working on the Worker's code

context: PlatformContext,
buildName: string,
buildNumber: string,
artifactsForPropertyUpdate: Set<ArtifactPathInfo>
Copy link

@cyrilc-pro cyrilc-pro Oct 6, 2025

Choose a reason for hiding this comment

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

Is there a reason for the update to use a Set, while the removal uses a Map?

// Simulate no previous builds
(context.clients.platformHttp.get as jest.Mock).mockResolvedValueOnce({
status: 200,
data: {buildsNumbers: [], buildInfo: {modules: []}}

Choose a reason for hiding this comment

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

Since we in the "after build save" event, I guess we will never get an empty list, it should always have at least one build, right?

});

it('should handle past build with module having no artifacts, but log a warning', async () => {

Choose a reason for hiding this comment

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

Suggested change

modules: [
{
id: 'module1',
artifacts: [

Choose a reason for hiding this comment

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

Add an artifact to cover the loop over artifacts

(context.clients.platformHttp.get as jest.Mock).mockResolvedValueOnce({
status: 200,
data: {
buildsNumbers: [{uri: '/12356'}],

Choose a reason for hiding this comment

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

Add another build to cover the loop over builds

);

for (const artifactInfo of artifactSet) {
await setProperty(context, artifactInfo.repo, artifactInfo.path);
Copy link
Contributor

Choose a reason for hiding this comment

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

This can also be parallelised.

@@ -0,0 +1,229 @@
import {PlatformContext, Status} from "jfrog-workers";
Copy link
Contributor

Choose a reason for hiding this comment

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

Please also consider cases where volume of artifacts is big. This might cause the Worker to timeout or reach the memory limit.

Copy link
Contributor

@christophermiJfrog christophermiJfrog left a comment

Choose a reason for hiding this comment

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

I left few comments, please consider them before we approve this Worker.

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.

3 participants