Clojurians Log v2

https://github.com/slipset/speculative/issues/105

https://github.com/slipset/speculative/pull/106

any objections against this PR?

from my perspective: we lose nothing, but only gain something (performance)

merged (after approval of slipset)

@slipset it seems like circleci also pushes snapshots to clojars when it builds PRs: https://circleci.com/gh/slipset/speculative/328#tests/containers/0

so maybe we could add something like ‘if PR, don’t push to clojars’

as you can see in this history: https://circleci.com/gh/slipset/speculative the latest two runs both produce a snapshot push to clojars

I think that script was fundamentally broken. it did a deploy for each CircleCI build:

Skipped command Created /home/circleci/repo/target/speculative-0.2.1-SNAPSHOT.jar

because lein deploy clojars was written between backticks, it would evaluate that regardless

I’m not sure how we can prevent users from deploying to clojars by sending a PR, because they can mess with the script.

so maybe deploying from circle is not such a good idea

or maybe circleci / github has some solution for this

@slipset improved two things now: PR doesn’t deploy and if any of us merge a PR, it is deployed from master.

Nice! Thanks for fixing that. Most probably my fault.

no problem. but there is still this security flaw

Oh, but they cant

They need my credentials 🙂

all they need to do is change the script and call lein clojars deploy I think?

Nope

It will then prompt for username/password

how come all these PRs were pushing to clojars?

and only I and you have access to that repo

sorry, not repo, I meant org.

Hrmf. I wanted to upload a picture of the circle-ci settings page

No space left on clojurians organization

Import Variables

Add Variable
Add environment variables to the job. You can add sensitive data (e.g. API keys) here, rather than placing them in the repository.

Name	Value	Remove
CLOJARS_PASSWORD	xxxx	
CLOJARS_USERNAME	xxxx	

I see, this PR from bbr wasn’t pushed: https://circleci.com/gh/slipset/speculative/236

because you gave me authorization on circle, this works?

hmm.

I haven’t looked at the code, but any code that is built from my circle account can in theory be pushed to clojars, since I have set up the uname/password there.

So, as long as the PR is built by “me”, then it should be published to clojars, unless we have a check that checks only for builds on master.

All PRs by me were built and published to clojars, but not the one by bbr. I’m a bit puzzled.

I think I see why

You make your prs off your master branch?

not all the time no

Whereas bbr made his off a branch.

I think because my PR came from a branch in the slipset/speculative repo

and not from a different personal account

Yeah, that might just be.

But still, I think that if [ "$CIRCLE_BRANCH" = "master" ] && [ "$CIRCLE_USERNAME" = "slipset" ] should have handled that

I think we’re good then. As of now, only master branch will push to clojars, not PR branches in the same repo. This is needed, because the git commit sha must be attached to the POM that is pushed to clojars.

ie, we should only publish to clojars on master.

no, that didn’t work, because CIRCLE_BRANCH was master even if the PR came from branch_xxx

it’s the name of the branch the PR is going to

so also if we deploy locally, first make the change to the master branch, sync it locally and then do the deploy

this will have impact on http://cljdoc.org

(I tested the CIRCLE_BRANCH with an echo in a certain commit in a different branch)

ah, ok.

all clear then 🙂