CI: Rework artifacts handling #144
Labels
No labels
Android
CS::needs customer feedback
CS::needs follow up
CS::needs on prem installation
CS::waiting
Chrome
Design:: Ready
Design:: in progress
Design::UX
E2EE
Edge
Firefox
GDPR
Iteration 13 IM
Linux
MacOS
Need::Discussion
Need::Steps to reproduce
Need::Upstream fix
Needs:: Planning
Needs::Dev-Team
Needs::More information
Needs::Priority
Needs::Product
Needs::Refinement
Needs::Severity
Priority::1-Critical
Priority::2-Max
Priority::3-Impending
Priority::4-High
Priority::5-Medium
Priority::6-Low
Priority::7-None
Progress::Backlog
Progress::Review
Progress::Started
Progress::Testing
Progress::Triage
Progress::Waiting
Reporter::Sentry
Safari
Target::Community
Target::Customer
Target::Internal
Target::PoC
Target::Security
Team:Customer-Success
Team:Design
Team:Infrastructure
Team:Instant-Messaging
Team:Product
Team:Workflows
Type::Bug
Type::Design
Type::Documentation
Type::Feature
Type::Improvement
Type::Support
Type::Tests
Windows
blocked
blocked-by-spec
cla-signed
conduit
contribution::advanced
contribution::easy
contribution::help needed
from::review
iOS
p::ti-tenant
performance
product::triage
proposal
refactor
release-blocker
s: dart_openapi_codegen
s::Famedly-Patient
s::Org-Directory
s::Passport-Generator
s::Requeuest
s:CRM
s:Famedly-App
s:Famedly-Web
s:Fhiroxide
s:Fhiroxide-cli
s:Fhiroxide-client
s:Fhirs
s:Hedwig
s:LISA
s:Matrix-Dart-SDK
s:Role-Manager
s:Synapse
s:User-Directory
s:WFS-Matrix
s:Workflow Engine
s:dtls
s:famedly-error
s:fcm-shared-isolate
s:matrix-api-lite
s:multiple-tab-detector
s:native-imaging
severity::1
severity::2
severity::3
severity::4
technical-debt
voip
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: Matthias/conduit#144
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Plan:
next
conduit:next
andconduit:commit-<shorthash>
vX.Y.Z
conduit:vX.Y.Z
andconduit:vX.Y.Z-alpine
master
conduit:latest
,conduit:latest-alpine
cc @Weasy
Sounds good, but i am not completely sure about tags, or to be more precise from where and when the tags will be triggered and if then a
conduit:vX.Y.Z
docker image could be newer than alatest
image. Can that happen?Retention policies looking good to me. I don't think we have control over that on Dockerhub, but maybe we can apply to some opensource program to get more freebies.
The tags should be triggered "manually", when Timo decides to bump the version number and release a specific version of conduit (as he did with v0.2.0.).
I'm not sure if that could result in
conduit:vX.Y.Z
being newer (regarding the date) thanconduit:latest
, but it should still contain the same binary as in the build from master most of the time.Ok. To be sure, we could just let the
tag
-pipeline push thelatest
tags, too. Just to be safe.This has the (though unlikely) risk of running a pipeline for an old tag and overwriting the latest tag while doing so.
Hm...true. Then let's just do it like you wrote above. We can still change it if we run into problems.
Okay, I'll try to implement this today then.
Will be two MRs: One for next, one for master.
mentioned in merge request !187
mentioned in merge request !186
MR merged, this is done.
Follow-Up for auto-releases in different Issue