On Thu, May 17, 2018 at 5:45 AM, James Nord <jn...@cloudbees.com> wrote: > say I depended on BlueOcean. > If I tried to check that out and build it I am left with something that is > conmpletely dead on arival as it produces garbage on windows.
Not sure what that is about, but I guess someone should be fixing it? > Is the CI the only place that can deploy them? Daniel would know the actual authorization settings for the repository, but CI (or, technically, an Azure function triggered by CI) is the only thing that is _expected_ to deploy these artifacts. > If building an incremental from a PR then the hash is likely not enough (as > that may/will not be pushed back upstream) You can check out a commit hash from a fork. GitHub does not really care. > many people (maven repo admins) when > asked to add a mirror of a upstream release will just add it in to the main > mirror Well, tell them not to? > I can create a release can call it whatever I want and deploy it (subject to > access control on the repo server). Of course that is physically _possible_, just as deleting release artifacts is physically possible. :-/ Maven does not enforce these things. > so if you are making these release canditates pass the full suite, you > are then using them in production via promotion, but the version in them is > still a release candidate? the above is just confusing? There needs to be a consistent version number the whole way through the Pipeline, so “RC” is as good as any. It would be more confusing (and far harder) to retroactively relabel the same artifact with another version. -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr3sGE1w7eL%3DTCV5TMF3A%2BV6RxhFqGRi-cwzeojZ3Z1mNQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
