digital-asset/daml
1
1
Fork 0
mirror of https://github.com/digital-asset/daml.git synced 2024-09-20 01:07:18 +03:00
Code Issues Projects Releases Wiki Activity
2e8bb47ef5
daml/release/BUILD.bazel

60 lines
1.3 KiB
Python
Raw Normal View History

update copyright notices to 2020 (#3939) copyright update 2020 * update template * run script: `dade-copyright-headers update .` * update script * manual adjustments * exclude frozen proto files from further header checks (by adding NO_AUTO_COPYRIGHT files)
2020-01-02 23:21:13 +03:00
# Copyright (c) 2020 The DAML Authors. All rights reserved.
open-sourcing daml
2019-04-04 11:33:38 +03:00
# SPDX-License-Identifier: Apache-2.0
Enforce consistent formatting of BUILD files. (#412) * Add buildifier targets. The tool allows to check and format BUILD files in the repo. To check if files are well formatted, run: bazel run //:buildifier To fix badly-formatted files run: bazel run //:buildifier-fix * Cleanup dade-copyright-headers formatting. * Fix dade-copyright-headers on files with just the copyright. * Run buildifier automatically on CI via 'fmt.sh'. * Reformat all BUILD files with buildifier. Excludes autogenerated Bazel files.
2019-04-12 14:10:16 +03:00
load("//bazel_tools:haskell.bzl", "da_haskell_binary")
Build SDK head tarball directly (#3723) Previously, we constructed the tarball used by daml-sdk-head by first building the regular SDK release tarball only to the extract it, patch the version file and recompress it. This adds about 30-60s to every invocation of daml-sdk-head. This PR changes this by factoring out the logic from building the release tarball into a macro that we instantiate twice, once with the proper version file and once with a dummy HEAD version file set to 0.0.0. This does change the format of the sdk-head-tarball slightly, in particular the files are now located under sdk-0.0.0 instead of sdk-head. However, this doesn’t matter anyway afaik and I think the new format makes more sense anyway considering that the regular release tarballs have something like sdk-0.13.38.
2019-12-04 15:04:15 +03:00
load("util.bzl", "sdk_tarball")
open-sourcing daml
2019-04-04 11:33:38 +03:00
da_haskell_binary(
name = "release",
srcs = glob(["src/**/*.hs"]),
Rename hazel_deps to hackage_deps (#2789) * hazel_deps --> hackage_deps Mechanical change: ``` sed -i 's/hazel_deps/hackage_deps/g' $(ag -l hazel_deps) ``` * Hazel dependencies --> Hackage dependencies
2019-09-06 12:01:09 +03:00
hackage_deps = [
Refactor and speed up release script (#431) This rewrites the release script to be a lot simpler and significantly faster: - The artifacts are now declared in a separate yaml file which should make it easier for people to modify and doesn’t clutter the actual code. - There is only a constant number of calls to Bazel which speeds up the script quite a bit. I verified that the release artifacts are the same that we got before and I traced the calls to the jfrog binary in a fake release and ignoring order they are identical.
2019-04-12 15:57:37 +03:00
"aeson",
Fixes #1204: Release bindings and codegens to Maven Central. (#1205) * Fixes #1204: Release bindings and codegens to Maven Central. Upload the Java and Scala Bindings with the respective code generator binaries to Sonatype Open Source Repository Host for synchronization with Maven Central.
2019-06-17 16:37:49 +03:00
"async",
open-sourcing daml
2019-04-04 11:33:38 +03:00
"ansi-terminal",
"base",
Fixes #1204: Release bindings and codegens to Maven Central. (#1205) * Fixes #1204: Release bindings and codegens to Maven Central. Upload the Java and Scala Bindings with the respective code generator binaries to Sonatype Open Source Repository Host for synchronization with Maven Central.
2019-06-17 16:37:49 +03:00
"base64-bytestring",
open-sourcing daml
2019-04-04 11:33:38 +03:00
"bytestring",
"conduit",
"conduit-extra",
"containers",
Fixes #1204: Release bindings and codegens to Maven Central. (#1205) * Fixes #1204: Release bindings and codegens to Maven Central. Upload the Java and Scala Bindings with the respective code generator binaries to Sonatype Open Source Repository Host for synchronization with Maven Central.
2019-06-17 16:37:49 +03:00
"connection",
"cryptohash",
open-sourcing daml
2019-04-04 11:33:38 +03:00
"directory",
"exceptions",
Refactor and speed up release script (#431) This rewrites the release script to be a lot simpler and significantly faster: - The artifacts are now declared in a separate yaml file which should make it easier for people to modify and doesn’t clutter the actual code. - There is only a constant number of calls to Bazel which speeds up the script quite a bit. I verified that the release artifacts are the same that we got before and I traced the calls to the jfrog binary in a fake release and ignoring order they are identical.
2019-04-12 15:57:37 +03:00
"extra",
open-sourcing daml
2019-04-04 11:33:38 +03:00
"fast-logger",
"filepath",
Fixes #1204: Release bindings and codegens to Maven Central. (#1205) * Fixes #1204: Release bindings and codegens to Maven Central. Upload the Java and Scala Bindings with the respective code generator binaries to Sonatype Open Source Repository Host for synchronization with Maven Central.
2019-06-17 16:37:49 +03:00
"http-client",
"http-client-tls",
"http-conduit",
"http-types",
open-sourcing daml
2019-04-04 11:33:38 +03:00
"lifted-async",
"lifted-base",
"monad-control",
"monad-logger",
"optparse-applicative",
"path",
"path-io",
Refactor and speed up release script (#431) This rewrites the release script to be a lot simpler and significantly faster: - The artifacts are now declared in a separate yaml file which should make it easier for people to modify and doesn’t clutter the actual code. - There is only a constant number of calls to Bazel which speeds up the script quite a bit. I verified that the release artifacts are the same that we got before and I traced the calls to the jfrog binary in a fake release and ignoring order they are identical.
2019-04-12 15:57:37 +03:00
"process",
Fixes #1204: Release bindings and codegens to Maven Central. (#1205) * Fixes #1204: Release bindings and codegens to Maven Central. Upload the Java and Scala Bindings with the respective code generator binaries to Sonatype Open Source Repository Host for synchronization with Maven Central.
2019-06-17 16:37:49 +03:00
"retry",
open-sourcing daml
2019-04-04 11:33:38 +03:00
"safe",
"safe-exceptions",
Fixes #1204: Release bindings and codegens to Maven Central. (#1205) * Fixes #1204: Release bindings and codegens to Maven Central. Upload the Java and Scala Bindings with the respective code generator binaries to Sonatype Open Source Repository Host for synchronization with Maven Central.
2019-06-17 16:37:49 +03:00
"time",
open-sourcing daml
2019-04-04 11:33:38 +03:00
"text",
Fixes #1204: Release bindings and codegens to Maven Central. (#1205) * Fixes #1204: Release bindings and codegens to Maven Central. Upload the Java and Scala Bindings with the respective code generator binaries to Sonatype Open Source Repository Host for synchronization with Maven Central.
2019-06-17 16:37:49 +03:00
"temporary",
open-sourcing daml
2019-04-04 11:33:38 +03:00
"transformers",
"unliftio-core",
"unordered-containers",
"yaml",
"mtl",
Move POM file generation to Bazel rules (#374) * Move POM file generation to Bazel rules
2019-04-11 12:24:52 +03:00
"xml-conduit",
open-sourcing daml
2019-04-04 11:33:38 +03:00
],
Enforce consistent formatting of BUILD files. (#412) * Add buildifier targets. The tool allows to check and format BUILD files in the repo. To check if files are well formatted, run: bazel run //:buildifier To fix badly-formatted files run: bazel run //:buildifier-fix * Cleanup dade-copyright-headers formatting. * Fix dade-copyright-headers on files with just the copyright. * Run buildifier automatically on CI via 'fmt.sh'. * Reformat all BUILD files with buildifier. Excludes autogenerated Bazel files.
2019-04-12 14:10:16 +03:00
src_strip_prefix = "src",
open-sourcing daml
2019-04-04 11:33:38 +03:00
visibility = ["//visibility:public"],
Enforce consistent formatting of BUILD files. (#412) * Add buildifier targets. The tool allows to check and format BUILD files in the repo. To check if files are well formatted, run: bazel run //:buildifier To fix badly-formatted files run: bazel run //:buildifier-fix * Cleanup dade-copyright-headers formatting. * Fix dade-copyright-headers on files with just the copyright. * Run buildifier automatically on CI via 'fmt.sh'. * Reformat all BUILD files with buildifier. Excludes autogenerated Bazel files.
2019-04-12 14:10:16 +03:00
deps = [],
open-sourcing daml
2019-04-04 11:33:38 +03:00
)
Build SDK head tarball directly (#3723) Previously, we constructed the tarball used by daml-sdk-head by first building the regular SDK release tarball only to the extract it, patch the version file and recompress it. This adds about 30-60s to every invocation of daml-sdk-head. This PR changes this by factoring out the logic from building the release tarball into a macro that we instantiate twice, once with the proper version file and once with a dummy HEAD version file set to 0.0.0. This does change the format of the sdk-head-tarball slightly, in particular the files are now located under sdk-0.0.0 instead of sdk-head. However, this doesn’t matter anyway afaik and I think the new format makes more sense anyway considering that the regular release tarballs have something like sdk-0.13.38.
2019-12-04 15:04:15 +03:00
sdk_tarball("sdk-release-tarball", "//:VERSION")
open-sourcing daml
2019-04-04 11:33:38 +03:00
Build SDK head tarball directly (#3723) Previously, we constructed the tarball used by daml-sdk-head by first building the regular SDK release tarball only to the extract it, patch the version file and recompress it. This adds about 30-60s to every invocation of daml-sdk-head. This PR changes this by factoring out the logic from building the release tarball into a macro that we instantiate twice, once with the proper version file and once with a dummy HEAD version file set to 0.0.0. This does change the format of the sdk-head-tarball slightly, in particular the files are now located under sdk-0.0.0 instead of sdk-head. However, this doesn’t matter anyway afaik and I think the new format makes more sense anyway considering that the regular release tarballs have something like sdk-0.13.38.
2019-12-04 15:04:15 +03:00
sdk_tarball("sdk-head-tarball", ":HEAD-VERSION")
Reference in New Issue Copy Permalink