What is Woodpecker CI's approach to publishing artifacts?

[amirbarak]

Hi,

I'm considering adopting Woodpecker for my CI needs. Something I'm trying to understand is how do I easily see which artifacts were created from a build?

From what I can see, assuming my job creates some tarball and docker image - I'd need to go through the pipeline logs to see where the artifacts were pushed to. Is there some method of consolidating the "outputs" of a pipeline run to some page in the build results? If not, what is the intended usage in terms of accessing the output artifacts of a CI run?

I think the most similar discussion is #2282 but I don't think Woodpecker should store these internally. I'm mainly looking for a UI method of consolidating the pipeline outputs, although I'm happy to change the .vue's and open a PR if that's the only way.

[anbraten]

We are mainly using comments in the forge (gitlab) to link such things like https://woodpecker-ci.org/plugins/Deployments%20plugin does it for deployments as most of the developers in our team are most of the time working in gitlab and are only checking woodpecker logs etc in case sth is failing.

#2287 could also be interesting for you.

[amirbarak]

That definitely looks interesting @anbraten ! Thanks for that. Seems like UI plugins are still in discussion though?
I guess that means that if I'm looking for some quick PoC then I'd need to add a tab next to changed files?

[anbraten]

For such things (artifcats, deployments, test reports, ...) I think UI plugins would be really nice.
My idea was like this:

• In repo settings an admin can add a UI plugin. Ideally this would be done using a plugin store that provides basically plugins as json like the following as a lot of users are not really interested in writing such things by themself:

  {
    "id": "deployments", // a unique id of the plugin used
    "name": "Deployments", // the title used for the tab for example
    "location": "pipeline-tabs", // the place where the ui-plugin should be registered. for the beginning "pipeline-tab" (behind config, changes) and maybe "repo-tab" (behind branches, pr)
    "ui": "adaptive-cards-json" // the json defining the adaptive cards layout
  }

• Pipeline plugins for example a plugin used in the pipeline that does a helm deployment could call an api endpoint from woodpecker like: POST /api/ui-plugins/ with some data like: { plugin: 'deployments', data: '{ some json data }', context: { repo: 123, pipelineId: 123 } }

[p1gp1g]

You can publish the artifact as a generic package, with a rule to remove them after x days, eg. https://codeberg.org/UnifiedPush/android-connector/src/branch/main/.woodpecker/main.yml#L15

[amirbarak]

Thanks, though I opted to move away from woodpecker as a CI solution for my company. Cheers