search

bcbi / DeIdentification.jl

A Julia package for de-identifying CSV data sets
https://bcbi.github.io/DeIdentification.jl/latest/
MIT License
2 stars 2 forks source link

fix: re-enable semantic release #39

Closed ibacher closed 5 years ago

DilumAluthge commented 5 years ago

My concern with semantic-release is this: how does it interact with Registrator.jl/TagBot?

My understanding is that semantic-release creates Git tags. But the preferred workflow for registering Julia packages is to first register the release with Registrator, and then after the pull request is merged into the registry, then TagBot creates the tag.

In particular, I have noticed the Julia General registry maintainers specifically ask that we not make a tag until they have merged the pull request into the registry.

Is there a way to configure semantic-release to not create tags?

The conversations in these two threads might be helpful:

  1. https://github.com/JuliaRegistries/General/pull/670
  2. https://github.com/JuliaRegistries/General/pull/1103
ibacher commented 5 years ago

Good point and that's reasonable.

DilumAluthge commented 5 years ago

Also, perhaps you could email Fernando Gelin (he’s here at Brown) and ask him what they’ve ended up doing on their semantic release repositories?

Certainly it’s a nice workflow and makes releases convenient. It’d be nice if we could make it play well with the Julia workflow.

DilumAluthge commented 5 years ago

I guess the other thing we’ll need to figure out is how semantic-release interacts with Bors. I think semantic-release makes commits to master. But for Bors to be most effective, no one except Bors should be able to commit to master - that’s how we ensure the 100% guarantee that master is always green.

So we’d have to figure out how semantic-release would work in a repository with Bors enabled.

But first we have to figure out how semantic-release can work with the Registrator/TagBot workflow. Once we have that solved, we can figure out how semantic release will work in the setting of Bors.

ibacher commented 5 years ago

It looks like the ideal workflow is to use something like the semantic-release tool to automatically update the version number in Project.toml and generate release notes, based on structured commits. While neither the Python nor JS semantic-release version support the first part, it wouldn't be hard to extend them to do so. We'd also probably need some kind of bot to automatically add the comment to Julia to register the release.

The harder part is integrating this with bors. Ideally, we want the version to be generated just prior to bors merging into master, after tests are run, which means Project.toml needs to be updated right before the merge is done. This might be possible from Travis, but it would seem to require pushing a commit to the staging branch, which... I'm not sure is a good idea.

Basically, I'm imagining a flow like this:

PR -> bors [test] -> bors [staging] -> Update Project.toml (new part) -> bors[merge] -> Registrator -> TagBot

This might be a bit cleaner if bors RFC0322 ever materialises.

ibacher commented 5 years ago

Confirmed with Fernando that they haven't found a solution and were just dropping semantic release.