build artifacts #966
Comments
|
I like this approach |
|
I think that should be a job for a publish job to put those in a content repository of choice.. I like how drone currently does not handle artifacts, keeps things cleanly separated. |
|
The hosted drone.io seems to have this http://docs.drone.io/artifacts.html .. Maybe it works by publishing using some internal publishing function. |
|
Also you should have searched the issue system first: |
|
Thanks for the link, let's track in #306 to avoid duplicate issues. For an immediate solution, I recommend using the S3 plugin (or others) to archive files. It isn't perfect, but should work. We will probably do something similar to what is described here: It isn't really practical for Drone to build everything (code coverage, commiter analytics, code quality, dependency analysis, artifacts, etc) directly into the codebase. Yet people want all of these things inside Drone and more. How do we pick winners? And should we? Drone can't do Coverage better than coveralls or artifact management better than Bintray, for example, and if we try we will probably create something mediocre at best. I think a better strategy is to find a way to integrate 3rd party systems with Drone as described in #239 (comment). The tl;dr is that we will expose something similar to the GitHub Status API but for Drone. You will be able to tag builds with useful information, and links to external resources. We could, for example, create an artifact service (a separate server) that tightly integrates with Drone using the API and the Status API. It could look and feel like Drone. It could even have Drone's branding. It just might be a different url, and you would link to it from your build. I really think we could make the UX seamless. This approach allows for unlimited integrations, and can meet the needs of every Drone user no matter how obscure their needs may be. I would love to engage everyone in designing the Drone status API to support all of these different use cases. Open issue here: #927 |
Currently there is a problem in which content build as part of a build step does not persist to the next build step. The suggested solution is to push this content to a third party repository. However, that means there will be a useless artifact in that repository for at least a short period of time, which isn't what we should do through the life of the build. This commit attempts to address that by combining two build steps, in the hope they'll be executed in the same environment sequentially. See harness/drone#966
Currently there is a problem in which content build as part of a build step does not persist to the next build step. The suggested solution is to push this content to a third party repository. However, that means there will be a useless artifact in that repository for at least a short period of time, which isn't what we should do through the life of the build. This commit attempts to address that by combining two build steps, in the hope they'll be executed in the same environment sequentially. See harness/drone#966
|
any update? |
|
Really would love this. |
|
My team would also like to see this as a feature added to Drone! |
No way to get build artifacts (screenshots/logs/etc) created during test suite. Nice example of build-artifacts implementation https://circleci.com/docs/build-artifacts.
The text was updated successfully, but these errors were encountered: