Clojurians Log v2

I was following this bit of documentation, but I was fooled by the lower case letter in the environment variable $npm_TOKEN which should probably be capital letters: https://circleci.com/blog/publishing-npm-packages-using-circleci-2-0/

I have some trouble building certain jobs only when I pushed a tag:

workflows:
  version: 2
  ci:
    jobs:
      - test:
          filters:
            tags:
              only: /.*/

      - deploy:
          requires:
           - test
          filters:
            tags:
              only: /^v.*/

It seems the deploy tag is always running, regardless of a tag or not

(e.g. here: https://app.circleci.com/pipelines/github/borkdude/nbb/20/workflows/6ac1b355-0b99-4ec5-8e68-00a535f84f86/jobs/27)

The example at "Git Tag Job Execution - Deploy on tagged commit" here, also seems wrong: https://circleci.com/blog/publishing-npm-packages-using-circleci-2-0/

Adding:

branches:
              ignore: /.*/

but now it seems to not appear anymore in case of a tag... aaaaah

ffffffff.... how am I going to test this without making a gazillion useless releases?

any ideas @lee @rahul080327 @slipset?

@rahul080327 has joined the channel

so what I'm doing, I'm executing this:

bump-version (do (shell "npm version patch")
                   (shell "git push --atomic origin main"
                          (str "v" (:version (json/parse-string (slurp "package.json") true)))))

which pushes a new git tag + commit

and then circleci should always execute the test job + only the deploy job in case of such a tag

I've been mostly in GitHub Actions these days... Do I remember @slipset generalizing circleci tag based deploy support for clj-commons though?

See the top commit: it has no tag, yet the deploy job gets executed 😠

This is the config I currently have:

workflows:
  version: 2
  ci:
    jobs:
      - test
      - deploy:
          requires:
           - test
          filters:
            tags:
              only: /^v.*/

annoying!

Here is an example @slipset gave some time ago: https://github.com/clj-commons/fs/blob/master/.circleci/config.yml

yeah, I've looked at that

but I read now that those filters are applied in an OR fashion..

it's really confusing me

oh... OR... that seems counter-intuitive to me.

I've read several forum entries about this too, it doesn't make sense to me today. Maybe I should just try github actions for this

hmmm, it seems this is working now:

workflows:
  ci:
    jobs:
      - test:
          filters:
            tags:
              only: /.*/
      - deploy:
          requires:
           - test
          filters:
            branches:
              ignore: /.*/
            tags:
              only: /^v.*/

I'm not grokking why, are you?

no

Seems non-obvious to me too. Someone will enlighten us, I'm sure.

I think I'll just not use any of this filter stuff and just check programmatically what the current tag is

For rewrite-clj on GHA, I took the approach of https://github.com/clj-commons/rewrite-clj/blob/main/doc/04-maintainer-guide.adoc#releasing. Not sure if this concept works for circleci or for your versioning scheme.

I'm taking the bb tasks approach here which runs npm version which creates a git tag which is then pushed atomically with the new commit

and then CI can inspect whether the current commit related to a tag or not

and then deploy or not

ah ok... that sounds good.

so anyone who can commit, can trigger a release

Yeah, for rewrite-clj I preferred to restrict release trigger to repo owner.

ok, all fixed now using programming instead of config DSL: https://github.com/borkdude/nbb/blob/cc06810b06e703c60ba9751b3cb430407140d469/bb.edn#L60

nice!

Are the credentials available to all branches?

@glenjamin the npm credentials? that wasn't the problem, the problem was that the filters didn't work for me, but I figured it out a different way

Sorry, I should have been clearer: I was asking for a different reason. have you got it set so that untrusted builds can access those creds? The config file alone isn’t enough to protect credentials

no

you mean the "PRs can access secrets" kind of thing right? No I never do that