{"action":"created","issue":{"url":"https://api.github.com/repos/Cryptonomic/Conseil/issues/176","repository_url":"https://api.github.com/repos/Cryptonomic/Conseil","labels_url":"https://api.github.com/repos/Cryptonomic/Conseil/issues/176/labels{/name}","comments_url":"https://api.github.com/repos/Cryptonomic/Conseil/issues/176/comments","events_url":"https://api.github.com/repos/Cryptonomic/Conseil/issues/176/events","html_url":"https://github.com/Cryptonomic/Conseil/pull/176","id":375566631,"node_id":"MDExOlB1bGxSZXF1ZXN0MjI2OTgyMjQ2","number":176,"title":"Conseil-125: deploy and version on maven central","user":{"login":"ivanopagano","id":1067461,"node_id":"MDQ6VXNlcjEwNjc0NjE=","avatar_url":"https://avatars2.githubusercontent.com/u/1067461?v=4","gravatar_id":"","url":"https://api.github.com/users/ivanopagano","html_url":"https://github.com/ivanopagano","followers_url":"https://api.github.com/users/ivanopagano/followers","following_url":"https://api.github.com/users/ivanopagano/following{/other_user}","gists_url":"https://api.github.com/users/ivanopagano/gists{/gist_id}","starred_url":"https://api.github.com/users/ivanopagano/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/ivanopagano/subscriptions","organizations_url":"https://api.github.com/users/ivanopagano/orgs","repos_url":"https://api.github.com/users/ivanopagano/repos","events_url":"https://api.github.com/users/ivanopagano/events{/privacy}","received_events_url":"https://api.github.com/users/ivanopagano/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":2,"created_at":"2018-10-30T16:00:02Z","updated_at":"2018-12-20T09:19:07Z","closed_at":null,"author_association":"COLLABORATOR","pull_request":{"url":"https://api.github.com/repos/Cryptonomic/Conseil/pulls/176","html_url":"https://github.com/Cryptonomic/Conseil/pull/176","diff_url":"https://github.com/Cryptonomic/Conseil/pull/176.diff","patch_url":"https://github.com/Cryptonomic/Conseil/pull/176.patch"},"body":"This sets up the needed tools and configurations to publish an official artifact for the project on Sonatype/Maven\r\n\r\ncloses #125 \r\n\r\nTODO:\r\n- [x] setup a process and credentials for PGP signing\r\n- [ ] open an account on sonatype jira to publish at\r\n- [x] define a versioning process\r\n- [x] expose the current build version within a rest-endpoint\r\n- [ ] bump `major` version in the build from `0` to `1` ?\r\n\r\n## detailed process\r\n\r\nThe versioning policy is implemented as follows:\r\n 1. we read the current project `version` in sbt using git\r\n   - it looks for the latest _annotated git tag_ that looks like `ci-release-<n>` to figure out the latest git releaes counter `<n>`\r\n   - on top of that it computes a `major.yyww.####` version where\r\n     - `major` a major platform number starting from `1` **(it's currently set to `0` before the final merge)**\r\n    - `yyww` are 2-digit year and week in the year (starting from january 1, and not from the first sunday of the year)\r\n    - `####` is the afore-mentioned tag release counter `<n>`, _increased for the next version_, padded with leading `0` (e.g. \"0002\")\r\n  - a `-SNAPSHOT` suffix might be added by sbt based on the current \"dirty\" status of the local git staging area (adding a relative insurance about unwanted publishing of a WIP)\r\n 2. we want to release from a role-restricted \"single-click\" operation triggered manually from the CI environment, that would execute the following steps\r\n   - clone the latest `master` branch\r\n   - build-test-publish by running \"`sbt test publishSigned sonatypeRelease`\"\r\n       the artifact will have the currently computed version (bullet-point `1.`) and will be signed using `PGP` (more on how to configure this later)\r\n   - tag a new release on the local repo by running `sbt gitTag` (that will produce the next `ci-release-<n+1>` annotated tag)\r\n 2. after the automated release steps complete, the user _must_\r\n   - manually verify that everything went well and that the produced tag is correct\r\n   - push the latest tag to origin `git push origin --tags`\r\n\r\n### PGP signing\r\nthe `pgp` credentials should be made available locally in a file with the following structure\r\n```yaml\r\nrealm=Sonatype Nexus Repository Manager\r\nhost=oss.sonatype.org\r\nuser=<sonatype-user>\r\npassword=<sonatype-password>\r\n```\r\n\r\nThis file should be \"made available\" to sbt by putting a global sbt file for the CI user in a\r\n`<user-home>/.sbt/1.0/sonatype.sbt` file with content like the following\r\n\r\n```scala\r\ncredentials += Credentials(Path.userHome / \".sbt\" / \"sonatype-cryptonomic.credentials\")\r\n```\r\nin this case the credential file should be in the `<user-home>/.sbt/sonatype-cryptonomic.credentials` file.\r\n\r\nWe might expect some problem when trying to first publish on sonatype, as I have no previous experience to build upon and cannot make any test locally against the real repository.\r\n\r\nOne possible issue on publishing might be related to [this issue with the plugin](https://github.com/sbt/sbt-pgp/issues/72)\r\n\r\n## goals\r\nWhat does the policy obtains?\r\n\r\n - we can generally refer to the currently deployed version using a simplified identifier (e.g. \"1.1846\"), without having git hashes in the version number, or having a meaningless sequence of numbers\r\n - the current build has always an updated version number, with no need to manually keep it in sync\r\n - there's a specific tagging policy in place (the `ci-release-n` format) that will be enforced by the sbt build, and can be triggered with a single command from CI\r\n - the tagging policy is referred-to within the exact version of the artifact (exposed as an http endpoint, too) so that it should be easy to figure out _what code_ is currently running on any environment\r\n\r\nDownsides?\r\n\r\n - our versioning policy differ from the most commonly used \"semantic versioning\"\r\n - there's not much wiggle room wrt the tagging, implying that custom created tags will not be picked up in the project version if they don't comply to the `ci-release-n` format"},"comment":{"url":"https://api.github.com/repos/Cryptonomic/Conseil/issues/comments/448928660","html_url":"https://github.com/Cryptonomic/Conseil/pull/176#issuecomment-448928660","issue_url":"https://api.github.com/repos/Cryptonomic/Conseil/issues/176","id":448928660,"node_id":"MDEyOklzc3VlQ29tbWVudDQ0ODkyODY2MA==","user":{"login":"ivanopagano","id":1067461,"node_id":"MDQ6VXNlcjEwNjc0NjE=","avatar_url":"https://avatars2.githubusercontent.com/u/1067461?v=4","gravatar_id":"","url":"https://api.github.com/users/ivanopagano","html_url":"https://github.com/ivanopagano","followers_url":"https://api.github.com/users/ivanopagano/followers","following_url":"https://api.github.com/users/ivanopagano/following{/other_user}","gists_url":"https://api.github.com/users/ivanopagano/gists{/gist_id}","starred_url":"https://api.github.com/users/ivanopagano/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/ivanopagano/subscriptions","organizations_url":"https://api.github.com/users/ivanopagano/orgs","repos_url":"https://api.github.com/users/ivanopagano/repos","events_url":"https://api.github.com/users/ivanopagano/events{/privacy}","received_events_url":"https://api.github.com/users/ivanopagano/received_events","type":"User","site_admin":false},"created_at":"2018-12-20T09:19:07Z","updated_at":"2018-12-20T09:19:07Z","author_association":"COLLABORATOR","body":"> This PR is approved but the Travis CI build is failing.\r\n\r\nThe PR failed because the test expects that the most recent ancestor commit with an annotated git-tag should have the format `ci-release-<n>`, but there was your tagged release `2018-December` that breaks the format.\r\n\r\nAs you see the `push` build is once again passing, as I committed another formally compliant release tag.\r\n\r\nThis would entail that every time `master` should happen to be tagged with a custom label, the test will break...\r\nIf this is too tight a constraint, I might\r\n 1. simply make the test more lenient, without any expectations on the version format (accept any tag history)\r\n 2. remove the constraint completely, trying to relax expectations on the git tagging history when we compute a new version for the build \r\n\r\nI won't here repeat the versioning logic, which is described in detail in the PR description and content.\r\nThe expectation here is maybe too brittle... that every published artifact will be released through the sbt commands here-to defined, from CI environment, and that essentially no other custom tag can be pushed without temporarily affecting the whole process.\r\n\r\nAs I'm thinking through this, it might make sense to assume that the tagging is done just before the publishing, and only then pushed to the repo master. That would at least guarantee that every official artifact will be correctly versioned.\r\nAs for the test, we might go as far as create a tag locally before any test and remove it immediately after, to guarantee the test outcome... (sounds a bit far-fetched though)..."}}
{"actor":{"display_login":"ivanopagano"}}